No, just thinking in terms of build vs. new dependencies. We need to look at the XPath component and see how easy it would be the mate it to HiveMind. Or we could just do an XPath-lite.
http://jakarta.apache.org/commons/jxpath/index.html -- 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 8:54 AM > To: [EMAIL PROTECTED] > Subject: Re: [HiveMind] more on BuilderFactory > > > > Could be a step in the right direction .... the question > is: how much > > of > XPath do we support? A > > little as possible, I think. > > > > Yes, I used XPath here; but it was more about illustrating > how I think the processing elements could be restructured > into a more intuitive form. Of course something else could > be used as well. But I thought XPath would be a good match > for this kind of thing. For example, it could be convenient > to access values of parent or child elements. Why do you > think as little as possible of XPath should be supported? > Because you intend to support OGNL and/or Jython in the > future? I like XPath because you can only navigate with it. > > > > > So ... translators become xpath functions ... that's cool. > > > > A possibility in XPath. But I haven't thought much about it... > > > I like this concept because its more unique to HiveMind, > rather than > > just > a crippled version of > > Digester. > > > > As I see it the HiveMind processing rule mechanism is a > hybrid of a stripped down RelaxNG (to define the syntax) and > an XMLified Digester (to define the correspondance in Java > code). IMHO the syntax for the processing rules could be > much improved. I've been playing with different ideas and > came up with the solution presented in the last mail. > > Another approach would be to split the syntax definition and > the rules part and use a pattern matching style (a la XSLT) > for the rules. This makes it easy to read for a user of the > configuration or service. Continuing with the same example: > > <element name="task"> > <attribute name="order" required="true"/> > <attribute name="title" required="true"/> > <attribute name="class"/> > <attribute name="service-id"/> > <element name="invoke-static"> > <attribute name="class" required="true"/> > <attribute name="method"/> > </element> > </element> > > <rules> > <template match="/task"> > <property setter-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)}"/> > <apply-templates/> > </object> > </property> > </template> > <template match="/task/invoke-static"> > <property setter-method="setExecutable"> > <object class="com.oubliette.framework.startup.service.StaticTask"> > <property name="className" value="[EMAIL PROTECTED]"/> > <property name="methodName" value="[EMAIL PROTECTED]"/> > </object> > </property> > </template> > </rules> > > Note that I also replace the <invoke-parent> elements by a > <property> with a "setter-method" attribute. > > --knut > > > -- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
