commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: [Digester] How to change when rules fire
Date Sat, 17 Sep 2005 04:56:25 GMT
Simon Kitching wrote:
> 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
> listItem.

Yes, your right, I'm not at all sure what I was thinking!

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

I think this was the part that was confusing me.  Now it makes sense... 
each CallParamRule that fired was overwriting the previous one, so when 
the CallMethodRule finally fired, obviously only the last value was 
still around.

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

Well then I'm OK with it too :)

What I meant by not elegant was that having to build an intermediary 
array seemed like a bit more work than was neccessary... I was thinking 
there might be a way to just rewrite the rules and not have to do that. 
  But, if that's a relatively normal usage pattern, then I have no 
reason to complain.  I just didn't want to feel like I was doing 
something "hackey".

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

Hmm... I think I get what your saying... I don't think it really fits 
what I'm doing though... I suppose in a sense, by design, the XML 
doesn't actually match the data structure being constructed.  I'm not 
actually populating individual items here, I'm populating a collection.

What I have is an initLists List.  Each element in this collection is a 
Map that contains three values: "name", "value" and "method".  So, for 
each item I add to that collection, I need not only the values that are 
part of a <listItem>, but also part of the <initList> element.

I think my flaw originally was in thinking I needed a way to store the 
method attribute of <initList>, so that I could use it for each 
occurance of <listItem>, which would fire some rule to add it to the 
collection.  As soon as I reversed the thinking and tried to store all 
the <listItem>'s first and THEN get the method attribute (in essence), 
it all fell in to place.

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

I suppose that could be made to be true, but as it stands now I don't 
have any ObjectCreate rules... well, not for the initList anyway, that 
is just a member of another object that in fact was created earlier. 
The resetting is done because there can be multiple <initList> elements, 
and each time a new one is encountered I effectively need to start 
building a new temporary array.

Although, now that your making me think about it, what I could do is put 
a CallMethod rule on the closing element that is the parent of 
<initList>, and not do the reset.  Then, the initList field would only 
be set once, and I could just set it to the temporary array.

Eh, it's working now, I'm not going to mess with it :)  I do very much 
appreciate your comments though Simon, if nothing else this has taught 
me a fair amount about Digester (I seem to learn a fair amount every 
time I use it actually!)

> Cheers,
> Simon


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

View raw message