On 7/1/05, David Zülke <[EMAIL PROTECTED]> wrote:
> > Yeah... I think we're all coming to the same conclusions here..
> >
> > We just had an internal discussion, and briefly, here's what the results
> > were:
> >
> > Message object is cool. I'll rename it AgaviMessage (avoid stepping
> > on toes), build a constructor that'll handle 3 params by default: a
> > string (message), an integer (verbosity/log
> > level/{INFO,WARN,ERROR,DEBUG}), and another string (destination).
> > This destination will be the name of a key in the [loggers] section of
> > logging.ini (ie which logger instance to send it to).
>
> Uh oh... the destination doesn't belong there, IMO. A message shouldn't know
> where it's being logged, this is what LoggerManager::log() or whatever does,
> after all. This would be of great advantage, also for interoperability of
> messages. Think about passing one message to multiple loggers, for instance
> (although I'm an advocate of the Observer approach, as you know :p)
>
We were thinking you could also pass an array of "destinations" as
well.. so it would be sent to multiple loggers.. I failed to mention
that. Mike was big on keeping the destination within the Message
object, so that our log() method wasn't tied to anything more than a
Message object as a parameter.. which (after much heated debate) I see
the benefit in. He kept whacking me over the head with some Martin
Fowler book ;)
>
> > We came to the same conclusion you did: there's a lot of value in
> > being able to extend the Message class.
> >
> > We agreed that the Message object would be responsible for translating
> > whatever it's logging (be it an object, a string, whatever..) into a
> > string, which will then get passed along to the appropriate Logger and
> > in-turn the Appender(s).
>
> Why that? It's not flexible!? Maybe I want to "attach" data to the message
> or whatever. Translating it is no good. We should just pass the untouched
> object to the logger.
>
Sorry, I think I chose my words poorly. We'd pass along the Message
object, but it would be up to that Message object to (at some point
down the road) provide a toString() method. (of course it may provide
lots of other methods!) The Logger/Appender shouldn't be the ones
translating the Message into a string... or at least that's what we
were talking about this afternoon.
I was thinking the Layout object would only be providing things like
timestamp prepending, coloring, etc.. *modifying* the string output of
the Message object, not buildling the actual output.
I don't know.. now I'm thinking I need to go back and re-evaluate what
the Logger object is really "doing" other than holding references to a
number of Appenders.
>
> > There may still be some hashing to be done as to whether or not to
> > make the Logger level use the Observer pattern as you and Mike have
> > suggested, but that'll be an easy leap to make once I complete the
> > ideas we've outlined in this thread.
>
> Yeah well but it's a different design then. We have two options:
> 1. (Bob): Tell a message or the logger manager which logger to use
> 2. (Mike/David): Broadcast messages to all loggers which themselves decide
> what to do about the message (process it; discard it).
It's not that I don't see the benefit of the second method. I like
Observers too ;) I don't know.. I just think I see it as YAGNI. I
know what loggers I set up. I know which logger(s) I want to send
this message to when I create the Message... why spend the time
sending the Message EVERYWHERE POSSIBLE when I can just direct it down
to the Loggers I want to see it. I know it allows for expansion down
the road, so maybe that's the bottom line.
>
>
> - David
Obviously I'm not rushing into any of this ;) I know Mike's on
vacation until Tuesday, but maybe we can all argue about this in IRC
at some point =)
--Bob
>
>
> _______________________________________________
> agavi-dev mailing list
> [email protected]
> http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
>
_______________________________________________
agavi-dev mailing list
[email protected]
http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
