commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Digester question
Date Tue, 13 Nov 2001 14:10:27 GMT

On Mon, 12 Nov 2001, Tal Dayan wrote:

> Date: Mon, 12 Nov 2001 22:21:25 -0800
> From: Tal Dayan <>
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: Digester question
> Hello,
> I am new to this list. If there is a more appropriate place to ask Digester
> questions, please
> let me know.

This list is fine.

> Just downloaded Digester an hour or two ago and still trying to figure out
> the basics.
> The documentation (Package org.apache.commons.digester Description) says
> that SetNextRule is acting on the begin event of the child element. The
> source code of SetNextRule seems to have the action in the end() method.
> Which one is right ? What about the SetTopRule ?

It's actually done at in the end() method, precisely for the reason you
are after (so that the child has been initialized already).

> BTW, we would like to have the association between the child and the parent
> elements when the
> child element already has all the values filled.

This is a very common Digester usage pattern.  The important issue is the
order in which the rules are registered, because they are fired in that
order when an element is matched.  Consider a desire to parse the
following structure:

  <parent name1="value1" name2="value2">
    <child name3="value3" name4="value4"/>
    <child name3="value5" name4="value6"/>

where you want to call parent.addChild() after each child object has been
created and initialized.  The appropriate rules would be set up like this:

  digester.addObjectCreate("parent", "com.mycompany.ParentClass");
  digester.addObjectCreate("parent/child", "com.mycompany.ChildClass");
  digester.addSetNext("parent/child", "addChild",

When each child is processed, the following actions take place:
* A new child instance is created and pushed on to the object stack
* The child instance's properties are populated from the attributes
* The "addChild(ChildClass)" method of the parent object (which was
  pushed onto the stack by virtue of the <parent> rule matching),
  passing the child instance as an argument
* The child instance is popped off the stack (in the cleanup
  processing of the object create rule

As long as you register the set properties rule before the set next rule,
the child instance will have been configured already before being added to
the parent's list of child objects.

> Thanks,
> Tal


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

View raw message