You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by rich coco <ra...@starbak.com> on 2004/07/22 15:10:23 UTC
Re: [digester] parsing xmlrpc message
bill/simon/bob -
thanks to all of you for your advice.
Unfortunately (for me) I do not see how the wildcard rule helps me,
tho this may be more do to my lack of imagination that anything to
do with the rule itself.
I'll try to explain why i think that. refer to the attached xmlrpc msg
(that i have to parse) in what follows. In general, the xmlrpc response
has this format:
* exactly one argument is returned, an unnamed (top-level) structure.
* Each member of that single argument is iteslf a (level-2) structure.
* From this point on, each member of a level-2 structure can be a
primitive (int, string, etc...), another structure, or an array
of any supported type (including structure).
* In principle, there is not limit to the depth of structures:
structures can have members that structures, whose corresponding
members may be structures, etc. (or even arrays thereof).
So with this in mind, and refering to the sample xml below, it is not
clear to me that a wild-card prefic rule like "*/struct" (or any rule of the form
"*/whatever/...").
Since the first 2-levels of the xmlrpc response have well defined (as opposed
to arbitray and recursive) structure, maybe I might use a wild-card rule like this:
/memberResponse/params/param/value/struct/member/value/struct/*/struct
to capture all level-3 and deeper structures? (similarly for arrays?).
One of you clued me in to the fix to the NodeCreateRule bug. thanks.
just today i downloaded the latet Digester cvs code and rebuild the jar file.
I had been getting an exception when using it precisely because it did not
pop an element off the Digester stack when it was supposed to (the bug). The man page
for that Rule gave this detailed warning about how using the rule would supress
the firing of subsequent rules (or some such), which made me think maybe that was
how it was supposed to work. tho, in retrospect, it's behavior made it
somewhat unusable, which should have been a clue to me...
Any additional insight welcome.
- rich
-------------
<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>status</name>
<value>
<struct>
<member>
<name>encoding</name>
<value><i4>200</i4></value>
</member>
<member>
<name>content_info</name>
<value>
<struct>
<member>
<name>description</name>
<value></string></value>
</member>
<member>
<name>encoder_info</name>
<value>
<struct>
<member>
. . .
Simon Kitching wrote:
> On Thu, 2004-07-22 at 08:27, robert burrell donkin wrote:
>
>>you may need to use the ExtendedBaseRules (or create a regex rule
>>implementation from something like ORO) if the base pattern matching
>>rule vocabulary is not rich enough but it's hard to give you more help
>>without the idea of the xml and the source to which you're trying to
>>map.
>>
>
>
> Digester does handle recursive structures, at least for the basic cases.
>
> The standard rules engine allows wildcard prefixes, eg
> "*/window/widget"
>
> This pattern will match both of the "widget" tags, firing the same Rule
> (which is generally what is desired).
>
> <gui>
> <window>
> <widget id="1"/>
> <window>
> <widget id="2"/>
> </window>
> </window>
> </gui>
>
> If this doesn't give you what you want, please let us know why.
> As Robert said, there are a number of other pattern-matching engines
> (ExtendedBaseRules and RegexRules) that might work for you.
>
> Regards,
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
--
rich coco
racoco@starbak.com
781.736.1200 x165
Starbak Inc.
29 Sawyer Rd.
One University Office Park
Waltham, MA 02453
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [digester] parsing xmlrpc message
Posted by Bill Keese <bi...@tech.beacon-it.co.jp>.
I think what Simon said explains exactly how to do it. I would only add
one thing. There's a common misunderstanding people have when learning
Digester, and I wonder if you are making that mistake.
People think: "When I call addCreateObject(), it scans the input XML for
a tag matching the pattern and then creates an object on the stack". But
actually, that's not what happens at all. All the calls like
addCreateObject() just add a rule into a table. They don't even look at
the input XML. After you are finished creating all the rules, digester
sequentially processes each tag/attribute in the input XML, by applying
matching rule(s) to it.
So, the rules don't necessarily execute in the order that you wrote them
in the java source code. And, a single rule can execute many times, on
elements in different levels of the input XML. The end effect is that
you get something like recursion, although it's implemented using the
digester stack.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [digester] parsing xmlrpc message
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-07-23 at 01:10, rich coco wrote:
> bill/simon/bob -
>
> thanks to all of you for your advice.
>
> Unfortunately (for me) I do not see how the wildcard rule helps me,
> tho this may be more do to my lack of imagination that anything to
> do with the rule itself.
>
> I'll try to explain why i think that. refer to the attached xmlrpc msg
> (that i have to parse) in what follows. In general, the xmlrpc response
> has this format:
>
> * exactly one argument is returned, an unnamed (top-level) structure.
>
> * Each member of that single argument is iteslf a (level-2) structure.
>
> * From this point on, each member of a level-2 structure can be a
> primitive (int, string, etc...), another structure, or an array
> of any supported type (including structure).
>
> * In principle, there is not limit to the depth of structures:
> structures can have members that structures, whose corresponding
> members may be structures, etc. (or even arrays thereof).
>
> So with this in mind, and refering to the sample xml below, it is not
> clear to me that a wild-card prefic rule like "*/struct" (or any rule of the form
> "*/whatever/...").
>
> Since the first 2-levels of the xmlrpc response have well defined (as opposed
> to arbitray and recursive) structure, maybe I might use a wild-card rule like this:
>
> /memberResponse/params/param/value/struct/member/value/struct/*/struct
>
> to capture all level-3 and deeper structures? (similarly for arrays?).
>
> One of you clued me in to the fix to the NodeCreateRule bug. thanks.
> just today i downloaded the latet Digester cvs code and rebuild the jar file.
> I had been getting an exception when using it precisely because it did not
> pop an element off the Digester stack when it was supposed to (the bug). The man page
> for that Rule gave this detailed warning about how using the rule would supress
> the firing of subsequent rules (or some such), which made me think maybe that was
> how it was supposed to work. tho, in retrospect, it's behavior made it
> somewhat unusable, which should have been a clue to me...
>
> Any additional insight welcome.
>
> - rich
>
> -------------
>
> <methodResponse>
> <params>
> <param>
> <value>
> <struct>
> <member>
> <name>status</name>
> <value>
> <struct>
> <member>
> <name>encoding</name>
> <value><i4>200</i4></value>
> </member>
> <member>
> <name>content_info</name>
> <value>
> <struct>
> <member>
> <name>description</name>
> <value></string></value>
> </member>
> <member>
> <name>encoder_info</name>
> <value>
> <struct>
> <member>
> . . .
>
Presumably you have a Java class which represents the info in a <value>
tag, and another class that represents the info in a <struct> tag,
right? So:
digester.addCreateObject("*/value", Value.class);
// the pattern "*/value/struct could simply be "*/struct", because
// they always do occur within a value tag, but putting the value
// in there makes the expected structure clearer.
digester.addCreateObject("*/value/struct", Struct.class);
digester.addSetNext("*/value/struct", "addStruct");
digester.addCallMethod("*/value/i4", 1, setIntValue);
digester.addCallParam("*/value,i4);
etc...
I don't see anything in your input that can't be handled with wildcard
prefixes (though I haven't investigated in detail). Although the spec
appears to be specific about the first 2 levels of nesting being
mandatory, they appear to have exactly the same hierarchy/nesting rules
that apply to the levels below that. So the same parsing rules should
work at any depth as far as I can see.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org