commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Tarkenton <tarken...@gmail.com>
Subject Re: [Digester] basic usage problem. Help me understand the stack.
Date Tue, 27 Jul 2004 01:50:08 GMT
Craig, thanks again, man.  You've helped me several times in the past
on the struts list.  I see exactly what I was missing.  Pushing that
dummy Part object to the top of the digester stack makes perfect sense
now that you wrote it out for me -- well that and adding the addPart
method to the Part class for recursion purposes.  That solution is so
obvious yet I couldn't wrap my head around it all day today.

Thanks again.

/Dan

On Mon, 26 Jul 2004 17:34:59 -0700, Craig McClanahan <craigmcc@gmail.com> wrote:
> On Mon, 26 Jul 2004 18:40:48 -0400, Rich Coco <racoco@starbak.com> wrote:
> > if you are simply trying to caoture all occurrences
> > of <part>, the the pattern you want is "*/part" i believe.
> > It will find that element at all depths.
> 
> Yes, this is quite useful.
> 
> In addition to the examples that Simon pointed you at, you might want
> to grab a build of the Commons "chain" sources.  In the
> org.apache.commons.chain.config package, you'll see a use of Digester
> that leverages the "*/part" style to deal with recursive configuration
> file structures.  A simplified version of this idea is presented
> below.
> 
> >
> > however, if you care about *where* the <part> element occurs -
> > eg, if it is (recursively) embedded inside other elements that you
> > you also have to tuen, say, into java objects of which a collection of
> > Part objects is a member (and maybe this higher level object is
> > embedded in an even higher level object that is represented by an
> > xml element) - then you have a much harder problem.
> >
> > I am confronting it myself, but have had to turn my attention away
> > from it for the next week or so. i would be delighted to hear if you
> > implement a truly recursive solution. i'd like to steal it!
> > (at least the implementation design part of it).
> >
> 
> Actually, there's a fairly straightforward and elegant solution to
> this sort of problem, if you have control over the object types being
> constructed.  For example, assume you have something like this,
> representing a part (say, in a bill of materials explosion) that has
> sub-parts:
> 
>     package mypackage;
> 
>     import java.util.ArrayList;
>     import java.util.List;
> 
>     pubic class Part {
> 
>         // An "id" property for this part
>         private String partId;
>         public String getPartId() { return partId; }
>         pubic vod setPartId(String partId) { this.partId = partId; }
> 
>         // Add a new sub-part for this part
>         public void addPart(Part part) {
>             parts.add(part);
>         }
> 
>         // Retrieve the sub-parts for this part
>         private List parts = new ArrayList();
>         public List getParts() {
>             return parts;
>         }
> 
>     }
> 
> Now, you can construct a recursive hierarchy of parts with some very
> simple Digester rules (assuming you push onto the stack an empty part
> to collect all the top-level children):
> 
>     // Set up the digester
>     Digester digester = ...;
>     digester.addObjectCreate("*/part", "mypackage.Part");
>     digester.addSetProperties("*/part");
>     digester.addSetNext("*/part", "addPart", "mypackage.Part");
> 
>     // Push a dummy Part onto the stack to collect all the top-level parts
>     Part dummy = new Part();
>     digester.push(dummy);
> 
>     // Parse the XML document
>     digester.parse(...);
> 
>     // Now, process the top-level parts we parsed
>     Iterator parts = dummy.getParts().iterator();
>     while (parts.hasNext()) {
>         Part part = (Part) parts.next();
>         ...
>     }
> 
> And you can deal with arbitrarily nested part hierarchies:
> 
>     <parts>
>         <part ...>
>         </part>
>         <part ...>
>             <part .../>
>             <part .../>
>         </part>
>     </parts>
> 
> > good lucj
> >
> > - rich
> 
> Craig
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
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