commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [digester] rule that constructs a non-bean from parameters
Date Thu, 11 Mar 2004 22:35:39 GMT
On 10 Mar 2004, at 23:58, Simon Kitching wrote:


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


> 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:
For additional commands, e-mail:

View raw message