This splits the existing logger class into a more modular architecture, allowing for easier implementation of loggers for other targets (AMQP, GELF, systemd, etc).
I'm not sure about the interfaces, so please take a look and comment. Also method and class names are not final yet. Feedback welcome.
I also looked at existing logging subsystems, specifically monolog (https://github.com/Seldaek/monolog), but it seemed too abstract and not modular enough.
Any opinions on this?
None
Loading file attachments...
1
0
2
1
4
Description
From
Last Updated
Why do you return an array with the bare message and the message + prefix? and more important why does ...
Why do you return an array with the bare message and the message + prefix? and more important why does the comment say it's a string??
The comment is wrong. The message splitting is in order to be able to still have a debug core dump in the browser in a similar format as you'd see if you used the php error logger.
In a log file however, you want additional datetime information.
We could move the datetime part into the log function. I'm not sure. It would allow to return a string here, but semantically the datetime is still part of the message so doing it outside of compose_message seems wrong.
Maybe we then need to rename it to compose_base_message() or some such.
I'm fine with the function returning an array if there is a use for both items. I didn't see why you would want the message without the timestamp. Also keeping it as an array would make it easier if we want to extend the message later in some way
Main reason for leaving out the timestamp is consistancy with the xdebug error format. Errors logged to files don't appear in the browser, so by default you only see them when checking the log file.
We call an xdebug method to make them visible, but then they should have a similar format.
The format of the message can be altered any way we want, having it an array or not has no influence on that.
The short message is kind of a summary of the issue. The full message could contain way more information, like a stack trace, dumps of certain variables, etc.
Ok, so it's kind of an open field, we don't have defined exactly what would go there. I was wondering because here you only use the short_message
I only use the short message because there is no more information to provide.
Felipe
