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