I did not - like I suggested - create a new tag instead I use the standard <configuration> tag for the schema definition. I extended the <create- instance> tag to include the new (optional) attribute configuration-id and to allow xml-parameters under it.
If the configuration-id attribute is present the CreateClassServiceConstructor will first get the schema (here is the dirty casting), than create with the class-attribute (like normal) the implementation, than pushes it on the processor and than processes the xml- parameters and finally returns the result.
For an example of how to use it see the hivemind.test.service.CreateInstanceContri.xml (hivemodule) file.
On Wed, 24 Sep 2003 17:44:41 -0400, Howard M. Lewis Ship <[EMAIL PROTECTED]> wrote:
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]
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
patch.zip
Description: Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
