Could be a step in the right direction .... the question is: how much of XPath do we support? A little as possible, I think.
So ... translators become xpath functions ... that's cool. I like this concept because its more unique to HiveMind, rather than just a crippled version of Digester. -- 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: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden > Sent: Tuesday, October 07, 2003 6:28 AM > To: [EMAIL PROTECTED] > Subject: Re: [HiveMind] more on BuilderFactory > > > The more I think about this, the more I wonder if the XML > processing rules and the BuilderFactory could be joined. > Afterall, they do very similar things... > > Unlike in Digester the the HiveMind processing rules are > written in XML. So how about using a more declarative > notation? Take the schema from the "Startup" configuration > point of the case study (descriptions skipped): > > <element name="task"> > > <attribute name="order" required="true"/> > <attribute name="title" required="true"/> > <attribute name="class"/> > <attribute name="service-id"/> > > <rules> > <create-object > class="com.oubliette.framework.startup.service.Task"/> > <read-attribute attribute="order" property="order" > translator="int"/> > <read-attribute attribute="title" property="title"/> > <read-attribute attribute="class" property="executable" > translator="class"/> > <read-attribute attribute="service-id" > property="executable" translator="service"/> > <invoke-parent method="addElement"/> > </rules> > > <element name="invoke-static"> > <attribute name="class" required="true"/> > <attribute name="method"/> > <rules> > <create-object > class="com.oubliette.framework.startup.service.StaticTask"/> > <read-attribute attribute="class" property="className"/> > <read-attribute attribute="method" property="methodName"/> > <invoke-parent method="setExecutable"/> > </rules> > </element> > </element> > > What if this were written in a more declarative way > (resembling a pipeline as in Cocoon or Jelly) using XPath > navigations to access attribute values: > > <element name="task"> > > <attribute name="order" required="true"/> > <attribute name="title" required="true"/> > <attribute name="class"/> > <attribute name="service-id"/> > > <rules> > <invoke-parent method="addElement"> > <object class="com.oubliette.framework.startup.service.Task"> > <property name="order" value="{int(@order)}"/> > <property name="title" value="[EMAIL PROTECTED]"/> > <property name="executable" value="{class(@class)}"/> > <property name="executable" value="{service(@service-id)}"/> > </object> > </invoke-parent> > </rules> > > <element name="invoke-static"> > <attribute name="class" required="true"/> > <attribute name="method"/> > <rules> > <invoke-parent method="setExecutable"> > <object > class="com.oubliette.framework.startup.service.StaticTask"> > <property name="className" value="[EMAIL PROTECTED]"/> > <property name="methodName" value="[EMAIL PROTECTED]"/> > </object> > </invoke-parent> > </rules> > </element> > > </element> > > Note that I've used an AVT notation as in XSLT here (e.g. > [EMAIL PROTECTED]) and the translators are accessed as XPath functions. > > Just an idea that occured to me. > > --knut > > > I had a few more ideas on how BuilderFactory can be improved. These > > improvements mainly address the usage and extensibility of the > > service. > > > > Right now the BuilderFactory is very flexible, but this comes at a > > cost: > the > > syntax is fairly complicated: there are four attributes and 17 > > different nested elements... > > > > I have been thinking if all the <set...> elements could be replaced > > with a single <property> element. This element could then have a > > "translator" (or > > "type") attribute; e.g. > > > > <property name="foo" value="22" translator="int"/> > > > > Having a single element would of course mean that the translator > > feature > of > > the XML processing rules can't be used anymore, as the rules don't > > provide conditional processing mechanisms. But the > translation could > > also be performed by the service itself, as the translator > to be used > > is given. If there were some kind of translator registry the > > BuilderFactory could then also easily support new (even custom) > > translators, without requiring its syntax to change. E.g. > > > > <property name="foo" value="22.33" translator="float"/> > > > > This idea could of course even be taken a step further. The > > "translator" attribute could be skipped all together. Then > the type of > > the > corresponding > > setter's attribute would tell BuilderFactory what > translator to use. > > Afterall, the type specified by the setter needs to be > matched by the > > translator. So specifying the type of the property in the > > hivemodule.xml might be considered redundant by the user. > > > > But what about <set-configuration> and <set-service>? If the setter > > specifies a java.util.List parameter, then the corresponding > > configuration could be looked up, and if an interface is > required then > > a service could > be > > looked up. As a consequence setters with a List parameter could only > accept > > configurations, when used by HiveMind. If this is too > restrictive, the > > "translator" attribute could be optional, in which case also other > > translators could be used for List setters. > > > > Analogously, all constructor elements could be collapsed > into a single > > <constructor> element. But here the "translator" should maybe be > > required, as finding the appropriate constructor could be hard > > otherwise. > > > > What do you think about this idea? Would this work or have I missed > > something important here? I could take a stab at implementing an > > optional service implementing this strategy? > > > > Would it make sense to add a HiveMind configuration for Translators? > > > > Regards, > > > > --knut > > > > > --------------------------------------------------------------------- > 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]
