commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [Digester] How to change when rules fire
Date Sat, 17 Sep 2005 00:27:59 GMT
On Thu, 2005-09-15 at 01:02 -0400, Frank W. Zammetti wrote:
> Hi everyone,
> I have a situation where I need to parse some XML that looks like this:
>    <dependencies>
>      <dependency>
>        <initList name="children" method="addChild">
>          <listItem value="Andrew" />
>          <listItem value="Michael" />
>        </initList>
>      </dependency>
>    </dependencies>
> What I want to have happen is that for each <listItem> element 
> encountered, I want to call this method of the top object on the stack:
>    public void addInitList(String inMethod, String inName,
>      String inValue);
> ...where the inMethod and inName parameters get their value from the 
> parent <initList> element.  Here's what I've done:
>    digester.addCallMethod("dependencies/dependency/initList", 
>      "addInitList", 3);
>    digester.addCallParam("dependencies/dependency/initList", 0,
>      "method");
>    digester.addCallParam("dependencies/dependency/initList", 1,
>      "name");
>    digester.addCallParam("dependencies/dependency/initList/listItem", 2,
>      "value");
> Now, this works, sort of... what actually happens is only the last 
> <listItem> encountered triggers the call to addInitList().

No, it isn't the last <listItem> that's triggering the call. The method
call always happens once for every match of the CallMethodRule. You've
specified a pattern of "dependencies/dependency/initList" for that rule,
so it fires once for each initList element found, *not* for each

When a CallParamRule fires it just stores its value away for use when
the method call actually happens, which is why you see the last
listItem's value as the parameter to the call.

Your later email describes a solution where the initlist object
effectively has a list of listItem objects which are added to the parent
initList as the listItem elements are encountered. The initList object
then has a method which adds all of its child listItem objects to the
root object after they have been processed. You describe this as "not
very elegant" but I think it's fine. The xml is clearly indicating that
listItem objects are children of an initList object, and this solution
implements exactly that. The only thing that could possibly be called
"not very elegant" is the last step where the listItems are added to
some root object (effectively "denormalising" the data structure) rather
than simply adding the InitList object to its parent, leaving the data
in a structure which echoes the xml layout.

You do mention "resetting" the initList's list of children "for the next
group" but I don't think this is necessary is it? When the next
<initList> tag is encountered, a new InitList object should be created
which will of course have an initially empty list of children.



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

View raw message