As I've been looking for ways to reduce the verbosity of HiveMind MDDs, one thought struck me .... how about making service-id for <invoke-factory> optional, and default to hivemind.BuilderFactory. That's the case, 99% of the time!
As Marc Fleury says: "Defaults! Defaults! Defaults!" With autowiring working pretty darn well, perhaps we should allow a simplified <construct class="..."/> element as a even more concise way to invoke BuilderFactory? I've also been pondering having the BuilderFactory autowire writable List properties to the configuration id with the matching id. That raises some questions, such as: what if there's more than one List property? Definitely want to implement <interceptor-set> as a way to commonly apply interceptors to a range of services. Perhaps modules should provide a default package, and any class names for the module should be automatically qualified to the package, much as service ids are qualified to the module id. That would remove a large amount of repetition. I've also been thinking that we should find a way to generate the HiveDoc from the in-memory representation of the Registry, rather than trying to fake it by stitching together the individual XML files. This would allow the registry.xml to be a very different format than the MDDs, one that was more sematically rich. By that, I mean that we could understand the meaning of contributions properties (i.e., that's a service so make it a hyperlink). -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
