You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2004/03/10 23:52:52 UTC
[digester] rule that constructs a non-bean from parameters
i'm thinking of adding a rule that constructs a non-bean (in other
words, a type without an empty constructor) from the parameters
currently on the stack. i think that this would enable easier digester
of type such java.awt.Dimension which may commonly be mapped to xml
thus:
<dimension>
<x>1.0</x>
<y>1.2</y>
</dimension>
comments welcomed :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 4 Apr 2004, at 05:31, Simon Kitching wrote:
<snip>
> I just wanted to let you know that I am still interested in this, and
> to
> make sure we aren't duplicating efforts.
i'm not actively working on this at the moment.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-03-12 at 11:35, robert burrell donkin wrote:
> let me know when you're back and we'll have a think about backwards
> compatible solutions to emmanuel's problem.
Well .. I'm back ;-)
I'm playing with an alternative to CallMethodRule (currently termed
InvokeMethodRule) which fires as soon as its params are available. I
believe this functionality is needed in order to support the "immutable
object initialized from nested tags" feature that betwixt needs. I think
that it also would be a nice feature in general (as pointed out by
Emmanuel) - if it can be got to work properly.
There are some gotchas about interleaved and nested invocations, so it
may be a few days before I have anything I want to post.
I just wanted to let you know that I am still interested in this, and to
make sure we aren't duplicating efforts.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 11 Mar 2004, at 23:03, Simon Kitching wrote:
<snip>
> Personally, I think that anyone writing code to access package-private
> methods of Digester should expect their code to break with later
> releases...
the usual rules are a bit different here (see
http://jakarta.apache.org/commons/releases/versioning.html). i'm a big
believer in backwards compatibility. one of the reasons why jakarta
commons has been successful is that there has been continuity and
compatibility. but this would certainly be a option for a digester 2.0.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
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
Re: [digester] rule that constructs a non-bean from parameters
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 10 Mar 2004, at 23:58, Simon Kitching wrote:
<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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-03-11 at 12:02, robert burrell donkin wrote:
> it's really a way to provide better support for immutable objects
> (which Dimension is not. Doh!)
>
> On 10 Mar 2004, at 22:52, robert burrell donkin wrote:
>
> > i'm thinking of adding a rule that constructs a non-bean (in other
> > words, a type without an empty constructor) from the parameters
> > currently on the stack. i think that this would enable easier digester
> > of type such java.awt.Dimension which may commonly be mapped to xml
> > thus:
> >
> > <dimension>
> > <x>1.0</x>
> > <y>1.2</y>
> > </dimension>
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.
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.
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).
Given:
digester.addCreateComplexObject("foo/bar", "java.awt.Point", 2);
digester.addConstructorParam("foo/bar/x", 0);
digester.addConstructorParam("foo/bar/y", 1);
digester.addSetNext("foo/bar", "addPoint");
this will fail badly, because the SetNextRule's end method will fire
before the AddCreateComplexObject's end method, ie before the object is
created.
Of course the same currently happens with this:
digester.addObjectCreate("foo/bar", "StringBuffer);
digester.addCallMethodRule("foo/bar", "append", 0);
digester.addSetNext("foo/bar", "addStrBuf");
The SetNextRule fires before the CallMethodRule, so the object passed to
the addStrBuf object is not (yet) initialized. However the impact is far
less critical; at least the StringBuffer object *exists*, and the target
of the addSetNext doesn't *normally* care that the target isn't
initialized.
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 :-)
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.
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.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] rule that constructs a non-bean from parameters
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
(for those who are paying close attention) this is a poorly chosen
example. (i should probably turn my computer off now and go straight to
bed 8-)
it's really a way to provide better support for immutable objects
(which Dimension is not. Doh!)
- robert
On 10 Mar 2004, at 22:52, robert burrell donkin wrote:
> i'm thinking of adding a rule that constructs a non-bean (in other
> words, a type without an empty constructor) from the parameters
> currently on the stack. i think that this would enable easier digester
> of type such java.awt.Dimension which may commonly be mapped to xml
> thus:
>
> <dimension>
> <x>1.0</x>
> <y>1.2</y>
> </dimension>
>
> comments welcomed :)
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org