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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
