DataCollector for the symfony toolbar

[dbu]

see also https://github.com/egeloen/IvoryHttpAdapterBundle/blob/master/DataCollector/IvoryHttpAdapterDataCollector.php and https://github.com/misd-service-development/guzzle-bundle/blob/master/DataCollector/GuzzleDataCollector.php

i think this will also need to use some tags to discover additional clients that are defined as service.

[joelwurtz]

Can be done with a plugin i think, or a decorator if we don't want to depend on the plugin system

[dbu]

i think using the plugin system is good. my idea for the bundle is that it helps with plugins anyways.

[sagikazarmark]

With the History plugin this could easily be done. Another possibility is using AOP to catch all the HttpClient calls. It would be more generic and it would not require to add a plugin.

http://go.aopphp.com/

[dbu]

aopphp sounds interesting, but could have a rather massive impact on the rest of the application. i think the History plugin is exactly what we want. we need to have a system to active plugins into clients anyways, so this should be no big deal to use it.

[joelwurtz]

I was thinking some sort of StandalonePluginClient, which transform only one Plugin into an HttpClient / HttpAsyncClient (like the DataCollector thing will only add this with the HistoryPlugin to the actual HttpClient when in debug mode / toolbar activated)

[sagikazarmark]

What if the http client itself is already a plugin client? Also, I think it is not generic: you might be able to create an http client service without httplug bundle.

Although I agree that AOP could have an impact on the application itself, not sure if the history plugin is generic enough. That said, I agree it would be much nicer.

What if the AOP solution is placed in a separate bundle? Like HttplugDebugBundle? That would only be enabled in development mode, so that the impact on the production application would be zero. Does that make any sense?

[dbu]

i will try to get a first thing working at all, first :-) the aop debug thing should probably not be limited to symfony. but i am not sure, feels like going very far. the approach of the guzzle bundle is to tag every client service as guzzle client, so that plugins can be added in debug env.

[sagikazarmark]

Ok, I think this AOP thing is not top prio. It is rather something when you give a new game to the kid: he/she wants to play with it all the time. 😛

[sagikazarmark]

Is this solved?

[dbu]

fixed in #19