commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rich coco <rac...@starbak.com>
Subject Re: [digester] parsing xmlrpc message
Date Thu, 22 Jul 2004 13:10:23 GMT
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


Mime
View raw message