<snip>
I agree that some mechanism for doing this would be very useful.
I can't see any way to support both this feature (creation via non-default constructor) PLUS being able to make arbitrary calls to methods on the constructed object via CallMethodRule/SetNextRule.
In other words, the object can't be created and then mutated. It can either be created via ObjectCreatRule/FactoryCreateRule at element start, then mutated, or created at element end - but not both.
it would have to be created pretty much at the end since that's when the data is ready.
As you say, all immutable objects qualify. Even objects which are not immutable will work fine, as long as the user doesn't expect the Digester to mutate them :-). So Dimension would be fine too.
yep, that's the use case that we need to focus on.
I think that even with this limitation, such a rule would be an excellent tool to add.
One major issue though: the way that rules fire in reverse order at end regularly catches users out (see Diego's email of today in the commons-user list).
<snipped useful section i agree with>
Users will *really* care if the SetNextRule tries to pass the "parent" object to the "grandparent" object, which is what I believe will havven with the addCreateComplexObject example above.
yep
Of course all the above code is untested...I hope I'm right that this problem actually exists as described above :-)
i think that it does. i was very hasty in posting last night. this probably needs to be given a bit more thought.
Emmanuel Bourg raised a proposal for having CallMethodRule fire as soon as all of its params are available; we had a discussion on this list just a week or so ago ["CallMethodRule order, bug 12997"]. The proposal was rejected due to backward-compatibility issues, but would have avoided this. As this is a new Rule, I guess we could instead take that approach. It would make the new rule inconsistent with CallMethodRule behaviour, though.
we should probably look back at emmanuel's problem since i recall that we could solve it by using a separate stack.
NB: I'll be away next week on holiday, so please don't think I'm not interested if I don't respond to emails.
have fun :)
let me know when you're back and we'll have a think about backwards compatible solutions to emmanuel's problem.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
