Add logger plugin

[joelwurtz]

Actually don't know if this "normalizer" should be in the plugins library, WDYT ?

[dbu]

so the promise is handling the throwing?

[dbu]

by catching the exception, i mean.

[joelwurtz]

Yes when calling one of the callable passed to the then method, if it returns something then the value will go into the next onFulfilled callable, if it throw an exception it will go into the next onRejected callable.

[dbu]

i think it would make sense to have an own thing for that. did you know https://github.com/namshi/cuzzle ? something like this for PSR-7 would be really cool. i would create a RequestFormatter and ResponseFormatter interface in the utils and implement it with a StringFormatter for now. and later we can do the curl plugin. the formatters would have just one method format, keeping things interchangeable. normalizeToString and the like are tighter coupling.
the array conversion is a special case, we might want that simply as a method in the logger plugin even.

[sagikazarmark]

Do we really need this? I mean, the nornalizer could work (probably in the utils repo), but in case of Monolog for example, we could have a Monolog Formatter.

The point is that it is not really the plugin's responsibility IMHO.

Haven't know cuzzle before, but it's great.

[dbu]

yeah, i really love the idea of formatting a log so you can simply paste it on the cli to see what that request returned.

[dbu]

yeah, formatting belongs into utils. except the monolog (or maybe psr log?) normalizing, because that is specific to the task of logging. i think a formatter should return only string, not mixed or string|array, it would make little sense. we can also have an array normalizer in utils if we think there are other use cases, but i would not implement the Formatter interface with that.

[sagikazarmark]

Actually we could even format it to plain HTTP, so that we can directly send it with local testing clients.

I think request/response formatter interfaces should go into a separate package. With some basic implementations. Also, formatters should always format to string I think.

[sagikazarmark]

The logger plugin should probably not require the formatter to be injected. The underlying PSR3 implementation should provide a way to add custom formatters. Not sure if it is possible though.

[dbu]

The logger plugin should probably not require the formatter to be injected. The underlying PSR3 implementation should provide a way to add custom formatters. Not sure if it is possible though.

for the message, we need a formatter i think. but for the context i agree that we should try to push that to the logger and just pass the object, as we do with the $exception.

I think request/response formatter interfaces should go into a separate package. With some basic implementations. Also, formatters should always format to string I think.

not sure if we need a separate package for that. imho utils is a good place for this. its a psr 7 utility to format requests and responses as strings.

[sagikazarmark]

its a psr 7 utility to format requests and responses as strings.

I have a feeling that this utils repo will eventually get a bit fat. Also, I imagine the utils repo as a collection of utilities for httplug and clients. Putting too much stuff in it is not a good idea IMO. We could have a psr7-utils repo for strictly PSR-7 utilities, without Httplug and other client related stuff in it.

[dbu]

i am more afraid of too many repositories than of that thing becoming too fat. but i can see your reasoning. having several X-utils repositories sounds confusing too. lets make it a psr7-formatter repository then. that way its clear what its about. oh, or does something like that already exist?

[sagikazarmark]

having several X-utils repositories sounds confusing too.

psr7-utils, httplug-utils....I can't imagine more utils for now.

i am more afraid of too many repositories than of that thing becoming too fat

Thinking about this: Maybe a psr7-utils package would be good, because there can be several cases when we just want one small psr7 thing to be somewhere. So a common psr7-utils repo could mitigate this problem.

oh, or does something like that already exist?

Don't think so, at least I don't know about it.

[dbu]

fine for me. for the question whether there are existing tools, i asked the internets https://twitter.com/dbu/status/665090150339321856

[joelwurtz]

The Formatter thing in ivory http adapter was also used for that : https://github.com/egeloen/ivory-http-adapter/blob/master/src/Event/Formatter/Formatter.php

[joelwurtz]

So to make it short on the changes :

• Remove object to array transform and use the object directly in context
• Keep string normalization for the moment (but make an issue to have something more deep, like cuzzle in the future)

Ok for everyone ? @dbu @sagikazarmark

[dbu]

agreed. but the Normalizer should have an @internal annotation and clearly state its not meant to be reused. i guess that is still better than moving those methods into the plugin class.

[sagikazarmark]

👍

[sagikazarmark]

I think this begs the question: logs...what?

[joelwurtz]

I have moved normalizer to @internal should be good to merge.

[sagikazarmark]

Nice job @joelwurtz