OK.  I'm going to take a look doing this later tonight and submit some
updated patches for review.  It seems like good direction to go in.

-Mark

> -----Original Message-----
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 12, 2003 1:28 PM
> To: 'Log4J Developers List'
> Subject: RE: Chainsaw patch - Create Main Window in ChainsawAppender
> 
> 
> > ANY gui.  The gui implementation would need to implement a 
> > known interface,
> > something that accepted a reference to the Chainsaw model.  
> 
> Yep!  Although mentally I've always thought of that interface 
> as the Builder
> interface, rather than the GUI interface.  I figure a GUI 
> shouldn't really
> care where it gets it's model from in the same way the model 
> doesn't care
> what View is using it.  It means you have a separate class 
> for the builder,
> but more fine grained components is always a good thing IMHO, prevents
> sticky-coupled situations later.  
> 
> > So, we could have the default Main() implementation 
> > that ships with
> > Chainsaw
> 
> Thinking as I go along here about what you've said, yeah, maybe the
> ChainsawAppender IS the Builder interface! ChainsawAppender 
> just binds a
> Model (i.e. ChainsawAppender stops becoming _the_ model), and 
> some method
> for routing LoggingEvents to the Model, and constructs a particular
> configured GUI (using Main if given no other info in the 
> config).  We could
> have a Central GUI element somewhere with the registered/constructed
> Appender GUI's to show/hide particular GUI's.
> 
> > <appender class="org.apache.log4j.chainsaw.ChainsawAppender">
> >   <param name="viewer-class"
> > value="org.apache.log4j.chainsaw.DefaultViewer"/>
> > </appender>
> 
> That's excellent. I love it.
>  
> > Wow, that would be cool.  Is there something I am missing 
> here?  Some
> > dependencies that would mess this up?
> 
> It's probably minimal work to create the "default" impl that 
> behaves as it
> does already, and then we can go and create new GUI elements, 
> and open up
> the config api a bit later.  It's a good direction anyway.
> 
> cheers,
> 
> Paul Smith
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to