commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [digester] Rule for processing instruction?
Date Fri, 26 Sep 2003 03:08:44 GMT
robert burrell donkin wrote:

> On Thursday, September 25, 2003, at 09:36 PM, Craig R. McClanahan wrote:
>> robert burrell donkin wrote:
>>> hi janek
>>> i don't see any reason why we shouldn't put something to allow 
>>> access to processing instructions into digester. this probably means 
>>> storing the indexed processing instruction (just as your example 
>>> code does). probably worth giving a getting for the keys as well as 
>>> a per-instruction getter. rules would be able to access these 
>>> properties during their execution by calling the properties on 
>>> digester.
>>> 1. can anyone see any issues with this approach?
>>> 2. can anyone think of anything i've forgotten?
>> Wouldn't some use cases for processing instructions want to depend on 
>> the context in which they occurred?  If so, it might be nice to 
>> invent a syntax where you could match on them in rules, just like we 
>> match on element names.
> yes, i think you might be right. i can think of three distinct use cases:
> the first is where a standard (?element?) rule needs to know what 
> processing instructions have been encountered before it's called. this 
> would cater for the usage where context insensitive processing 
> instructions are given at the top of the file before the elements. 
> (this usage case is what i was thinking about before.)
> the second is when a processing instruction is encountered, an action 
> (rule) is fired and the rule or rules which are fired depends on the 
> element path. this could probably be done by adding an optional 
> processing instruction callback to Rule
> the third is allowing matching on processing instructions as well as 
> element names. IMHO this would need a bit of thinking about. for example,
> <alpha>
>     <? org.apache.commons.digester.COLOUR RED ?>
>     <beta>
>         <epsilon>
>             <? org.apache.commons.digester.COLOUR GREEN ?>
>             <beta>..</beta>
>         </epsilon>
>     </beta>
>     <? org.apache.commons.digester.COLOUR BLUE ?>
>     <beta>...</beta>
>     <gamma>...</gamma>
> </alpha>
> would only children of epsilon be able to match on 
> org.apache.commons.digester.COLOUR GREEN? would they want to match on 
> multiple instructions?
> in terms of implementations, i think that maybe matching on processing 
> instructions might be orthogonal to the more usual element matching. 
> maybe it'd be better to have a string for each (rather than a combined 
> syntax). 

<? thinking.out.loud ?>

Sorry ... couldn't resist :-).

IIRC, a "?" is not legal in the name of an XML element, right?  
Therefore, we could do something simple like say that a leading "?" in a 
pattern element would match a PI instead of an element, so we could just 
fire all the usual rules when matching 
"alpha/?org.apache.commons.digester.COLOUR" or 
"alpha/beta/org.apache.commons.digester.COLOUR" or even 
"*/org.apache.commons.digester.COLOUR" to catch them both.

We'd have to simulate the data value as an Attributes structure, and a 
couple of other wrinkles like that, but I bet this would cover a 
substantial number of use cases.

> BTW craig: are you still the person to ask about adding a project to 
> the nightlies?

Yep, for Commons and Struts.  If it's got an Ant build script, that 
makes life easiest on me.

> - robert 


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

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

View raw message