commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [Digester] basic usage problem. Help me understand the stack.
Date Tue, 27 Jul 2004 01:24:00 GMT
On Tue, 2004-07-27 at 13:17, Rich Coco wrote:
> but what if a Part object could be member of other objects 
> that are represented as xml elements, eg, consider an xmlrpc 
> msg fragment:
> <struct>
>   <member>
>     <name>Struct_1</name>
>     <value>
>       <array>
>          <data>
>            <value>
>              <struct>
>                <member>
>                  <name>Struct_2</name>
> .  .  .
> Struct_1 can contain a Part element (not shown).
> It also contains an array of Struct_2 elements,
> one of whose members can either be a Part or another
> structure containing a Part, etc...
> Suppose you need to parse the xml and return, say, a hashtable
> containing the associated java objects.
> you may assume you know a priori the definitions for all 
> structure types (in xml). and assume you even have alreay generated
> Java class definition for each such structure. (not hard using digester
> if you have an input spec (in xml of course) defining the strucures,
> giving them a name, specifying the members and their types, etc...
> it does not seem to me the "*/part" type of pattern will work.
> this approach does not keep the correspondence between a <part> strucuture
> and its parent container(s).
> it's a gnarly problem me i eventually have to solve.

If you need to treat Part objects differently depending upon their
parent element, then you can use these patterns:

Here, I presume that when processing a part nested within a part, it
doesn't matter what the parent of the top-level part is. I can't imagine
a scenario where this would not be the desired behaviour.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message