We probably need to discuss coding style issues. For instance, a lot of the new code I'm looking at is using protected instance variables. I favor private instance variables in almost all cases, even when I'm designing a class to be extended ... but then I provide protected or public accessor methods to those private fields.
What I haven't done in Tapestry or HiveMind, but am starting to do in Tapestry5, is to use "final" much more liberally. But that's another discussion. In addition, a note about HiveMind services and Log. If you have a writable property named "log" (i.e. setLog() is the setter method name), and the type is org.apache.commons.logging.Log, then HiveMind will autowire that property to a Log instance based on the *service* name (not the implementation class name). This is actually a function of the default service factory, hivemind.BuilderFactory. This is good for testing, since its easier to provide a mock implementation of Log than to deal with the Log created by the class for itself (the traditional approach). -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
