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] 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 thinks...one i eventually have to solve.

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

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.

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