commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] rule that constructs a non-bean from parameters
Date Thu, 11 Mar 2004 23:03:25 GMT
On Fri, 2004-03-12 at 11:35, robert burrell donkin wrote:
> On 10 Mar 2004, at 23:58, Simon Kitching wrote:
> >
> > 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.

Well, this email (which was posted on this list a few weeks ago)
provides some comments on Emmanuel's original patch, and an alternative
proposal.

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=107783392913490&w=2

This is also why I'm not particularly keen on making the digester param
stack accessor methods public; it would prevent us from making this sort
of change.

Alternatively, we could indeed have a separate stack; essentially have
an "old-style" param stack in order to avoid breaking compatibility with
user code that accesses package-private methods and a "new-style" param
stack.

Personally, I think that anyone writing code to access package-private
methods of Digester should expect their code to break with later
releases...

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message