commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Wannheden" <>
Subject Re: [HiveMind] more on BuilderFactory
Date Thu, 09 Oct 2003 17:25:57 GMT
Read the comments further down...

> >
> > 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>
> >
> The problem here is that without the explicit stack-oriented approach used
with Digester, it isn't
> clear what the top object on the stack is at the time the rules for the
invoke-static contribution
> are executed. This is because <invoke-parent> wraps around <object>.

I don't quite understand what you mean. The top object is the object that
was added (using <invoke-parent>) by the <rules> of the <element> one level
up.  In this example the nested <invoke-parent method="setExecutable"> would
pertain to the <object class="...Task"> of the enclosing <element
name="task">.  But to make it clearer the <object> and <invoke-parent>
should maybe be merged into a single element.

In this example I tried to maintain the same mix of syntax and processing as
in the current implementation. But the more I think about it the more I
think that these two things shouldn't be mixed at all.  Instead they should
be kept separate right from the beginning as I suggested in a later post.
If I understand Christian and Harish corretly they even seem to suggest to
decouple the two as separate services, which would let developers implement
their own.  I'd for example like to use RelaxNG for specifying (and
checking) the syntax and maybe an XSLT approach for processing.

But as it is now the two concepts are very intertwined.  To decouple the two
one would have to come up with a reasonably expressive, yet simple, default
implementation.  But as I see it this would at least require to change the
processing part.  One option would be to provide a very simple pattern based
approach, similar to what I described in another post.  Or of course
something like Digester.

> I have doubts that we'll be able to use XPath here, based on what the
current Translator classes
> need to operate; I may be wrong. I need to dig through the APIs to see how
to glue it together.
> Actually, perhaps the Digester model is the flawed part? I still like the
idea of a declarative,
> rules-based conversion of XML to objects ... how can we make it simpler?
> Right now, all we can safely do is change:
> <read-attribute property="..." attribute="..." translator="..."/>
> <read-content property="..." translator="..."/>
> to:
> <property name="..." value="..."/>
> Where the value attribute will have an XPath-like expression for reading
content or attribute and
> applying a translator-ish function upon the
> value before assigning it to the property.  I'm not seeing enough gain
there to make a change (the
> code change is easy, but its a lot of work to update the test suite).

The XPath notation was just an idea. Don't know whether it's a good one :-)
So I agree, that small change would probably not justify all the work it
implies.  But if, as I said, the syntax and processing parts were split it
would be a more drastical change, in which case the processing should
probably be reconsidered.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message