commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] parsing xmlrpc message
Date Thu, 22 Jul 2004 22:59:53 GMT
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


Mime
View raw message