On Friday, September 26, 2003, at 04:08 AM, Craig R. McClanahan wrote:
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.
sounds good so far :)
we'd probably need to have an ignorePIs flag that would start out true to avoid breaking existing patterns.
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.
why not just add a processingInstruction method to Rule?
here's my hypothetical example of a computer that is linked to a (robotic)
tea machine which can create a warm beverage whilst processing a particularly long xml document. for example:
... <alpha> <? org.apache.commons.digester.tea WARM POT ?> <beta>...</beta> <? org.apache.commons.digester.tea BOIL WATER ?> <gamma>...</gamma> <? org.apache.commons.digester.tea INFUSE ?> <delta>...</delta> <? org.apache.commons.digester.tea SERVE ?> </alpha> ...
the RoboticLinkRule would be mapped under <alpha> and then whenever it recieves a org.apache.commons.digester.tea PI it would send the correct signal through the firewire connection to the tea producing robot. (this is a use case that i can really relate to ;)
- robert
http://www.w3.org/TR/REC-xml#sec-pi says:
"PIs are not part of the document's character data <http://www.w3.org/TR/REC-xml#dt-chardata>, but must be passed through to the application."
To me this means that you shouldn't catch PI's but send them directly to 'the application'. So PI's aren't context sensitive?
I don't really understand what you can do with processing instructions that you can't do with 'normal' xml. Sending instructions to the tea machine can be done by subclassing Digester and overriding the processingInstruction method. Or by adding a CallMethod rule if the instruction is context sensitive.
However, I can imagine that you would want a PI to work on a particular rule/pattern in some scenarios where normal xml elements are semantically inappropriate. So I agree with Robert's suggestion of adding a processingInstruction method to Rule. Digester's default behaviour would be to send PIs to the appropriate Rule. Users wanting more direct access to PIs could subclass Digester and override the processingInstruction method, do their stuff with the PI and call super.processingInstruction(..) (if they want to).
Yours humbly, Matthijs.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
