i'm in the process of reviewing (and improving) Kelvin Tan's wildcard tail patch (allowing stuff like a/a/*). this could help with this circumstance - but i'm now a bit struck by the thought that making ExtendedBaseRules any more complex isn't really going to do much other than slow down the matching process.
rather than go on forever expanding EBRs, i'd favour an implementation of STX or XPath. any volunteers?
but this kind of problem could be solved by a mix and match approach. DepthMatchingRules would be easy to write, easy to use and quick. maybe we could write a Rules implementation (SplitRules? FilterRules?) that allowed different Rules implementations to be used to match different subtrees.
so, you might use EBRs by default but for matches in the children of a/b/c,
DepthMatchingRules or STXRules would be used. so path a/b/d would be matched by one Rules instance but a/d/c/d would be matched by another. we could make this more powerful by removing the head of the tree allowing disparate subtrees to be matched by the sames Rules implementation (if the user so wished).
comments?
- robert
On Wednesday, March 12, 2003, at 01:37 AM, Schnitzer, Jason D (US SSA) wrote:
Ok,
Thank you so much for all the suggestions here is what I did that works for how I need it.
Note this is just pseudo code. I am sure I could do it better. I just wanted to prove it could be done.
If someone had detailed questions I can copy more of the code in..
// Driver setup
// other rules .....
ValueRule valueRule = new ValueRule(); digester.addRule("/SomePath/To/What/I/Am/IntererestedIn/value", valueRule);
...
The supporting classes.
public class ValueRule extends Rule { .....
public void begin(String namespace, String name, Attributes attributes) throws java.lang.Exception { // Set up a new content handler to work in these situations.. // The content handler will be responsible for setting back the current // content handler so we can resume the normally scheduled program ContentHandler oldHandler = getDigester().getXMLReader().getContentHandler(); saxValueParser = new SaxValueParser(oldHandler, getDigester().getXMLReader()); this.getDigester().getXMLReader().setContentHandler(saxValueParser); super.begin(namespace, name, attributes); }
public void end(String namespace, String name) throws java.lang.Exception { Object peekObj = digester.peek();
((CastAway)peekObj).setValue(saxValueParser.getValue(); }
....... }
public class SaxValueParser extends DefaultHandler { .....
// Creates up a string that represents all the parts of the xml contained.
public void endElement(String uri, String localName, String qName) throws SAXException { // don't forget to set the old content handler back }
..... }
Good Luck, Jason
-----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 4:23 PM To: Jakarta Commons Users List Subject: Re: [Digester] Re: Unknown nodes in digester?
On Wed, 2003-03-12 at 12:18, Schnitzer, Jason D (US SSA) wrote:
<ROOT> <USERDEFINED> <UNKNOWN1></UNKNOWN1> </USERDEFINED> </ROOT>
I would like a way to store the <unknown1></unknown1> in a string inside of my class... So if I did
How about using NodeCreateRule, which deals with DOM nodes?
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
