I didn't see this earlier. It's another interesting idea; Basically, a more powerful version of BuilderFactory that supports a stack-oriented approach to constructing the service, similar to how contributions are processed into Java objects. I see this as something that could sit beside BuilderFactory unless it could be made as easy to use as BuilderFactory.
-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 24, 2003 3:26 PM > To: Jakarta Commons Developers List > Subject: [HiveMind] Re: Schema instead of BuilderFactory? > > > In case any of you missed it. > > Christian Essl wrote: > > > I am realy found of the idea of using the BuilderFactory. > > > > What I suggest is that you have like for > configuration-points also the > > possibility to define a schema(-processing) for the most important > > 'configuration' - the initial setup of a ServiceImplementation. > > > > Therefore I think a tag lets say <service-implementation > > class="implementingClass"> which contains a schema-processing > > definition would be useful. The <create-instance> tag could than > > contain the xml for the schema. When the rules of the schema are > > processed, the CoreImplementation would be on top of the > stack. (May > > be it could also be enforced that when for a class such a schema is > > given it can only be created with <create-instance>). > > > > Through the BuilderFactory which does this currently rather a > > 'property- scripting' aproach is given. I know the > BuilderFactory also > > has the point- id-attribute. However using this means more > typing for > > the user and the service-implementor and there is a > difference between > > service-construction configuration and contributed configuration > > (similar to java constructors and properties). > > > > I think the suggested approach has also other advantages. It would > > make the configuration of the Service easier and more clear than > > through the BuilderFactory. It would relieve the service of some > > initial state- checking. It would also provide better documentation > > about what are initialization (constructor-like) properties and > > 'normal' properties. Finally it would also make the whole > > 'BuilderFactory-aproach' more powerful. (Future stuff: I > was thinking > > of the late module loading and for this it would be very useful - > > because there would be a distinction between initial > configuration and > > contributed configuration.) > > > > For my problem (you know a clean-shutdown ;-)) it would certainly > > help. Currently I try to define the dependencies in a > > configuration-point (pro: the user can see the dependencies) but I > > think it should be bound to the implementation of the > Service, however > > also there I have my problems (the Service does not know > its id nor of > > its dependent services). I also think for other such 'in-between' > > things (like events) such a tag would help. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
