Kindly requesting your thoughts on Zend\Log - Only strings are accepted

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Kindly requesting your thoughts on Zend\Log - Only strings are accepted

Ludwig Ruderstaller
Hi,

Currently Zend\Log\Logger only accepts strings for writers. (you can
give an object or an array, but it has to implement __toString or
traversable).
(
https://github.com/zendframework/zf2/blob/master/library/Zend/Log/Logger.php#L220
)

My suggestion would be to let the writer decide if he accepts other
types then strings.

I dont know if this would be helpful for other writers, but it does in
fact limit the features of FirePHP.

FirePHP has the ability to display array's and object's in a very
comfortable way.

See http://s12.postimage.org/5ymv35ect/fb1a.png and
http://s12.postimage.org/726zf3yzx/fb1b.png for an example what it
looked like in ZF1.

When i only can give an string to the writer it will result in something
like this:
http://s12.postimage.org/h0wjfbxt9/fb2.png
Not very usefull, as no line breaks are supported.

Currently i use the $extra param and a own FirePHP Formatter to bypass
this. (which only works limited, as $extras supports no objects)

I understand that most other writers will only may handle strings, but
wouldn't it be better to have the writer decide it? This would also
allow to code custom Writers and even Formatters with more control over
what and how something is logged. (e.g custom Exception loging with
->getPrevious() functionalaty only can work if i can give the complete
Exception Object to the logger.)

What do you think?


Issue is opened at https://github.com/zendframework/zf2/issues/2638

TIA
Ludwig

--
Ludwig Ruderstaller
http://www.cwd.at
Reply | Threaded
Open this post in threaded view
|

RE: Kindly requesting your thoughts on Zend\Log - Only strings are accepted

demiankatz
I agree that more flexibility would be useful here.

My application uses an array of messages at different verbosity levels to allow logging of different versions of the same message to different writers.  I had to override the \Zend\Log\Logger::log method as well as creating custom writers in order to achieve this.  Perhaps it would make more sense if the writers themselves validated the format of the data in order to make extension easier.

I can also envision scenarios where passing a closure to the logger might make sense: i.e. if debug mode is turned on, you want to do some expensive analysis and return a message...  if debug mode is off, you need not ever perform the analysis.  Putting that work inside a closure passed to the logger helps avoid lots of "if debug is enabled, then..." logic spread through the code.

(Disclaimer: I don't have a whole lot of experience with logging, so perhaps my ideas could be better achieved in different ways...  but if my use cases make sense to others, then I definitely think \Zend\Log\Logger would benefit from more flexibility).

- Demian

> -----Original Message-----
> From: Ludwig Ruderstaller [mailto:[hidden email]]
> Sent: Wednesday, October 10, 2012 5:17 AM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Kindly requesting your thoughts on Zend\Log - Only
> strings are accepted
>
> Hi,
>
> Currently Zend\Log\Logger only accepts strings for writers. (you can
> give an object or an array, but it has to implement __toString or
> traversable).
> (
> https://github.com/zendframework/zf2/blob/master/library/Zend/Log/Logger.php#L
> 220
> )
>
> My suggestion would be to let the writer decide if he accepts other
> types then strings.
>
> I dont know if this would be helpful for other writers, but it does in
> fact limit the features of FirePHP.
>
> FirePHP has the ability to display array's and object's in a very
> comfortable way.
>
> See http://s12.postimage.org/5ymv35ect/fb1a.png and
> http://s12.postimage.org/726zf3yzx/fb1b.png for an example what it
> looked like in ZF1.
>
> When i only can give an string to the writer it will result in something
> like this:
> http://s12.postimage.org/h0wjfbxt9/fb2.png
> Not very usefull, as no line breaks are supported.
>
> Currently i use the $extra param and a own FirePHP Formatter to bypass
> this. (which only works limited, as $extras supports no objects)
>
> I understand that most other writers will only may handle strings, but
> wouldn't it be better to have the writer decide it? This would also
> allow to code custom Writers and even Formatters with more control over
> what and how something is logged. (e.g custom Exception loging with
> ->getPrevious() functionalaty only can work if i can give the complete
> Exception Object to the logger.)
>
> What do you think?
>
>
> Issue is opened at https://github.com/zendframework/zf2/issues/2638
>
> TIA
> Ludwig
>
> --
> Ludwig Ruderstaller
> http://www.cwd.at
Reply | Threaded
Open this post in threaded view
|

Re: Kindly requesting your thoughts on Zend\Log - Only strings are accepted

Axel
Am 10.10.2012 16:25, schrieb Demian Katz:

I briefly checked this and you're right. Zend\Log\Logger does indeed
check if $message is stringifyable and, even worse, converts the message
to a string before passing it to the writer instances.

This is completely out of the logger's domain. The writer should decide
how to handle the message.
So you could implement a writer storing more detailed exception
information, if one is passed to log(), which is not possible in the
current implementation.

This is awful and used to work in ZF1.
+1 for fixing this

> I agree that more flexibility would be useful here.
>
> My application uses an array of messages at different verbosity levels to allow logging of different versions of the same message to different writers.  I had to override the \Zend\Log\Logger::log method as well as creating custom writers in order to achieve this.  Perhaps it would make more sense if the writers themselves validated the format of the data in order to make extension easier.
>
> I can also envision scenarios where passing a closure to the logger might make sense: i.e. if debug mode is turned on, you want to do some expensive analysis and return a message...  if debug mode is off, you need not ever perform the analysis.  Putting that work inside a closure passed to the logger helps avoid lots of "if debug is enabled, then..." logic spread through the code.
>
> (Disclaimer: I don't have a whole lot of experience with logging, so perhaps my ideas could be better achieved in different ways...  but if my use cases make sense to others, then I definitely think \Zend\Log\Logger would benefit from more flexibility).
>
> - Demian
>
>> -----Original Message-----
>> From: Ludwig Ruderstaller [mailto:[hidden email]]
>> Sent: Wednesday, October 10, 2012 5:17 AM
>> To: Zend Framework Contributors
>> Subject: [zf-contributors] Kindly requesting your thoughts on Zend\Log - Only
>> strings are accepted
>>
>> Hi,
>>
>> Currently Zend\Log\Logger only accepts strings for writers. (you can
>> give an object or an array, but it has to implement __toString or
>> traversable).
>> (
>> https://github.com/zendframework/zf2/blob/master/library/Zend/Log/Logger.php#L
>> 220
>> )
>>
>> My suggestion would be to let the writer decide if he accepts other
>> types then strings.
>>
>> I dont know if this would be helpful for other writers, but it does in
>> fact limit the features of FirePHP.
>>
>> FirePHP has the ability to display array's and object's in a very
>> comfortable way.
>>
>> See http://s12.postimage.org/5ymv35ect/fb1a.png and
>> http://s12.postimage.org/726zf3yzx/fb1b.png for an example what it
>> looked like in ZF1.
>>
>> When i only can give an string to the writer it will result in something
>> like this:
>> http://s12.postimage.org/h0wjfbxt9/fb2.png
>> Not very usefull, as no line breaks are supported.
>>
>> Currently i use the $extra param and a own FirePHP Formatter to bypass
>> this. (which only works limited, as $extras supports no objects)
>>
>> I understand that most other writers will only may handle strings, but
>> wouldn't it be better to have the writer decide it? This would also
>> allow to code custom Writers and even Formatters with more control over
>> what and how something is logged. (e.g custom Exception loging with
>> ->getPrevious() functionalaty only can work if i can give the complete
>> Exception Object to the logger.)
>>
>> What do you think?
>>
>>
>> Issue is opened at https://github.com/zendframework/zf2/issues/2638
>>
>> TIA
>> Ludwig
>>
>> --
>> Ludwig Ruderstaller
>> http://www.cwd.at

Reply | Threaded
Open this post in threaded view
|

Re: Kindly requesting your thoughts on Zend\Log - Only strings are accepted

till-2
+1 for fixing this — Zend\Log is a little too hard to use in its current state.

I'd help writing code, if anyone wants/needs some help. :)

Till

On Sat, Oct 27, 2012 at 1:47 PM, Axel <[hidden email]> wrote:

> Am 10.10.2012 16:25, schrieb Demian Katz:
>
> I briefly checked this and you're right. Zend\Log\Logger does indeed check
> if $message is stringifyable and, even worse, converts the message to a
> string before passing it to the writer instances.
>
> This is completely out of the logger's domain. The writer should decide how
> to handle the message.
> So you could implement a writer storing more detailed exception information,
> if one is passed to log(), which is not possible in the current
> implementation.
>
> This is awful and used to work in ZF1.
> +1 for fixing this
>
>
>> I agree that more flexibility would be useful here.
>>
>> My application uses an array of messages at different verbosity levels to
>> allow logging of different versions of the same message to different
>> writers.  I had to override the \Zend\Log\Logger::log method as well as
>> creating custom writers in order to achieve this.  Perhaps it would make
>> more sense if the writers themselves validated the format of the data in
>> order to make extension easier.
>>
>> I can also envision scenarios where passing a closure to the logger might
>> make sense: i.e. if debug mode is turned on, you want to do some expensive
>> analysis and return a message...  if debug mode is off, you need not ever
>> perform the analysis.  Putting that work inside a closure passed to the
>> logger helps avoid lots of "if debug is enabled, then..." logic spread
>> through the code.
>>
>> (Disclaimer: I don't have a whole lot of experience with logging, so
>> perhaps my ideas could be better achieved in different ways...  but if my
>> use cases make sense to others, then I definitely think \Zend\Log\Logger
>> would benefit from more flexibility).
>>
>> - Demian
>>
>>> -----Original Message-----
>>> From: Ludwig Ruderstaller [mailto:[hidden email]]
>>> Sent: Wednesday, October 10, 2012 5:17 AM
>>> To: Zend Framework Contributors
>>> Subject: [zf-contributors] Kindly requesting your thoughts on Zend\Log -
>>> Only
>>> strings are accepted
>>>
>>> Hi,
>>>
>>> Currently Zend\Log\Logger only accepts strings for writers. (you can
>>> give an object or an array, but it has to implement __toString or
>>> traversable).
>>> (
>>>
>>> https://github.com/zendframework/zf2/blob/master/library/Zend/Log/Logger.php#L
>>> 220
>>> )
>>>
>>> My suggestion would be to let the writer decide if he accepts other
>>> types then strings.
>>>
>>> I dont know if this would be helpful for other writers, but it does in
>>> fact limit the features of FirePHP.
>>>
>>> FirePHP has the ability to display array's and object's in a very
>>> comfortable way.
>>>
>>> See http://s12.postimage.org/5ymv35ect/fb1a.png and
>>> http://s12.postimage.org/726zf3yzx/fb1b.png for an example what it
>>> looked like in ZF1.
>>>
>>> When i only can give an string to the writer it will result in something
>>> like this:
>>> http://s12.postimage.org/h0wjfbxt9/fb2.png
>>> Not very usefull, as no line breaks are supported.
>>>
>>> Currently i use the $extra param and a own FirePHP Formatter to bypass
>>> this. (which only works limited, as $extras supports no objects)
>>>
>>> I understand that most other writers will only may handle strings, but
>>> wouldn't it be better to have the writer decide it? This would also
>>> allow to code custom Writers and even Formatters with more control over
>>> what and how something is logged. (e.g custom Exception loging with
>>> ->getPrevious() functionalaty only can work if i can give the complete
>>> Exception Object to the logger.)
>>>
>>> What do you think?
>>>
>>>
>>> Issue is opened at https://github.com/zendframework/zf2/issues/2638
>>>
>>> TIA
>>> Ludwig
>>>
>>> --
>>> Ludwig Ruderstaller
>>> http://www.cwd.at
>
>