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] more on BuilderFactory
Date Tue, 07 Oct 2003 11:27:41 GMT
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:news@sea.gmane.org] On Behalf Of Knut Wannheden
> Sent: Tuesday, October 07, 2003 6:28 AM
> To: commons-dev@jakarta.apache.org
> 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="{@title}"/>
>     <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="{@class}"/>
>      <property name="methodName" value="{@method}"/>
>     </object>
>    </invoke-parent>
>   </rules>
>  </element>
> 
> </element>
> 
> Note that I've used an AVT notation as in XSLT here (e.g. 
> {@class}) 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: 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