commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] more on BuilderFactory
Date Thu, 09 Oct 2003 15:15:48 GMT
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 
<hlship@comcast.net> wrote:

> Been running around a lot, but found a few minutes to think about this in 
> more detail.
>
>> -----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):
>>
>
>>
>> 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 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>



-- 
--
Christian Essl http://jucas.sourceforge.net

---------------------------------------------------------------------
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