commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] Re: Schema instead of BuilderFactory?
Date Wed, 24 Sep 2003 21:44:41 GMT
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:hkrishnaswamy@comcast.net] 
> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


Mime
View raw message