Been running around a lot, but found a few minutes to think about this in more detail.
> -----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): > > > 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> > 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 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). -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
