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
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
