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:36:06 GMT
I think this way we could also solve that chicken-egg problem with rules 
and translators:

The HiveMind build in processing is kept. This build in processing is used 
by the ProcessingServices to have their rules, translators, xsl-functions 
etc defined/added. (ProcessingServices are only allowed to use the build 
in).

To differentiate between the build in processing and the 'custom- 
processing' the configuration-point tag is just checked wheter it contains 
a <processing> tag.

On Thu, 09 Oct 2003 11:20:09 -0400, Harish Krishnaswamy 
<hkrishnaswamy@comcast.net> wrote:

> Yeah, I like this idea. Options are good.
>
> 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 
>> <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
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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