I'm finding it difficult to follow this thread mainly because I'm not clear on what the requirements are.

So let me address the question: What do we actually want from the logging functionality?
  • In my code I want to be able to use the framework to log messages.
  • I will have set up different log destinations (in an ini file)
  • The messages will go either to all destinations or a subset of these destinations
  • Where it goes will be determined by a number of factors
    • I may be explicit in  my code naming a destination
    • I will have rules in an ini file indicating a group of destinations and my code will use that group
    • I will have rules in an ini file indicating the priority and the destination or group of destinations, and my code will set the priority
    • I don't give any advice in my code and so it will be determined by ini settings, if any.
This is the functionality that I can think of, what else do we want?

Once I get the requirements clear I can think design... ;)

graeme

Mike Vincent wrote:
On 7/1/05, Bob Zoller <[EMAIL PROTECTED]> wrote:
  
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 ;)
    

I'm big on encapsulating it and anything else being passed in the
message obj vs passing stuff  along side it.
log($msg) vs log($msg, $destination) vs log($msg, $priority, $destination) etc..

read that book, damnit! :)


  
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 missed that part of the discussion, I think, but I guess that's
fine. We'd still be giving the processing object the whole message
object.

  
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.
    

You're using observers, if I understand it correctly, it's just that
you're taking some of their responsability and transfering it to the
manager. And I think the YAGNI you see is actually the code in the
mirror (oh! back atcha!). Seriously, we have multiple implementations
in other areas of the framework, why's there need to be one logging
system to rule them all?
We -could- implement both, yea?

  
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 =)
    

Right and I wont be around a computer either. :)

So I'll see ya'll in a few days. 

-Mike
_______________________________________________
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

Reply via email to