commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Wannheden" <knut.wannhe...@paranor.ch>
Subject Re: [HiveMind] more on BuilderFactory
Date Tue, 07 Oct 2003 12:54:28 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.
>

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="{@title}"/>
    <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="{@class}"/>
    <property name="methodName" value="{@method}"/>
   </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: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