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 10:27:45 GMT
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


Mime
View raw message