Christian Essl wrote:
I am personally quite happy with the digester/translator aproach HiveMind uses currently.
I like Knut's suggestion to split up the validating schema from the processing.
Maybe in a later release of HiveMind it could be possible to use a something like this:
<configuration-point> <schema>....</schema> <processing service-id="ie digester-id or XSLT-id"> .... </processing> </configuratino-point>
The schema checks the elements and after this check the elements are given to the defined processing-service:
public interface ProcessingService{
public List getContributions(Element[] processingContent,Element[] contributions,String config-id);
}
I think this way the configuration-point definer could choose the form he want's to define/parse the contributions.
On Thu, 9 Oct 2003 08:35:43 -0400, Howard M. Lewis Ship <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
