Do you think that moving the AjaxDataCollector class alone makes sense? The actual data collecting is done on the client side.

If I am not mistaken then the AjaxDataCollector is the only part which is in the FrameworkBundle. The entire js which is used for data collecting is part of the WebProfilerBundle (please correct me if I missed something).

As for instance the silex/web-profiler is using the WebProfilerBundle as a dependency only moving the AjaxDataCollector is enough to be able to use the feature.

👍

To be backward compatible, you should at least keep an empty class with the same name in the FrameworkBundle which then extends the new one from the HttpKernel component.

@xabbuh thanks, pushed with your suggested change.

👍 for that

The old class should be marked as deprecated though (as of 2.8 as this will be merged into 2.8).

Status: reviewed

By the way, the HttpKernel requirement in the FrameworkBundle needs to be bumped to ~2.8.

@stof do you want me to add a deprecation warning as class doc and via trigger_error?

@glaubinix both

Why is this even a DataCollector?
it adds nothing to the profile and is only there so that the toolbar knows to render the Ajax block.

in my opinion we should remove the class entirely and make the toolbar capable of dealing with it.

@jelte having a data collector allows one to disable it or to change its priority (new in 2.8.)

Closing in favor of #16069 where I've added the deprecation notice.

@fabpot priorities are not new. They are supported since at least 2.1. However, all core collectors are using the same priority in 2.7 and older, making it harder to control the order to put it where you want

@fabpot I know that the DataCollector is a bit of a hack here, it's just not really proper as the DataCollector on its own is not used for anything.
More logically would be to add this to the configuration of the WebProfileBundle,
for example "intercept_ajax_calls: true".

Only problem this give is for the priorty, but personally I'd place it fixed on the right before the symfony version.

To me this is more a feature of the WebProfilerBundle then the FrameworkBundle or Profiler.

@jelte in the future we may add a new Ajax panel in the profiler to display the logged AJAX calls. That's why it's better to have a real collector, even if right now it's empty.

@javiereguiluz well in the future you won't need a DataCollector to add data to an existing profile. ( see #14809 for more info, DataCollectors would no longer be part of a Profile )
The function of a DataCollector is to collect data in my opinion, if it doesn't do that, it has no reason to exists.

In my opinion it would be better to remove it now and go with an option, as this would enable client side functionality (include additional javascript for intercepting ajax calls + the enabling it on the toolbar).
if it would be needed for something in the future it can be easily re-added as it's an empty class.

Anyway, I might work it out as an option in the future and make a pull request, so we can have a proper discussion about this instead of hijacking a closed one.