Paul, > Playing devils advocate here, there is also the "reverse" of > this model that > comes to mind. Thinking out loud here.. Where each configured > ChainsawAppender is purely the model in the MVC world. There > could then be > another class (perhaps a Builder style pattern) that queries the Log4j > system to find any GUI-style Appender's (where > ChainsawAppender is the first > one of this type, perhaps other styles later on). This > builder could then > construct the relevant GUI window and bind the model > (ChainsawAppender) to > it. > > ... > > This example is probably totally over the top, but hopefully > you can see the > flexibility. > > I guess the goal that this approach solves is that the > ChainsawAppender > doesn't know about it's visual representation. It's just a > Sink for the > data. Then you can unload any GUI elements, and the > (non-visual) Appender > keeps receiving events.
Oh man. Oh yeah, I think you have hit on something here! The ChainsawAppender acts as the model, as you say, but can be configured to use ANY gui. The gui implementation would need to implement a known interface, something that accepted a reference to the Chainsaw model. After that it could create any set of gui parts it wants to display/interacct with the model. So, we could have the default Main() implementation that ships with Chainsaw, but someone like Scott could create a new gui implementation, compatible with the ChainsawAppender and model, to display data the way they want. All controllable via the configuration file, something like: <appender class="org.apache.log4j.chainsaw.ChainsawAppender"> <param name="viewer-class" value="org.apache.log4j.chainsaw.DefaultViewer"/> </appender> <appender class="org.apache.log4j.chainsaw.ChainsawAppender"> <param name="viewer-class" value="com.scottdeboy.chainsaw.MyCoolGui"/> </appender> The ChainsawAppender activateOptions() would instantiate the configured class, call the required methods for setup, and then everything is going. If we do this, then we don't need to have a bunch of discussions about what set of features to move into Chainsaw for its gui. If someone wants a different way of viewing the model they can go ahead and implement it. And all they have to do is focus on the gui part, not the model or the receiver parts. Wow, that would be cool. Is there something I am missing here? Some dependencies that would mess this up? -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
