You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <si...@ecnetwork.co.nz> on 2004/02/11 23:56:05 UTC
[digester] Enhancing CallMethodRule to take target offset
Hi,
As discussed on the user list, there appears to be a need to make calls
on objects other than the top-of-stack in a manner more flexible than
the limited SetNextRule and SetRootRule.
Attached is a patch which adds a "targetOffset" attribute to the
CallMethodRule to indicate which object on the digester stack gets
invoked. The default value for the offset is 0, which is the old
behaviour for CallMethodRule (invoke method on top object).
If this is ok, I can commit this myself [first use of new apache commit
rights - yay!]
Notes:
(a) the test case uses SetNestedPropertiesRule. When factory methods for
this new rule were added to Digester, the main usage (no constructor
params) was omitted, so attached is a minor patch to fix this.
(b) several new constructors were added to CallMethodRule each taking an
int targetOffset as a first param. Selecting the target seems the
*first* thing to do, hence makes sense to me to make it the first
param..
(c) In CallMethodRule, if target object for call is found to be null, a
deliberate exception with a useful message is now thrown rather than
throwing a NullPointerException. I used a SAXException as I couldn't see
anything more appropriate. Alternate suggestions welcome.
(d) I haven't added factory methods on Digester for the new
CallMethodRule constructors. This usage isn't wildly common, so I'm not
sure the factory methods are really needed. We can always add them later
anyway.
Regards,
Simon
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi simon
the ideas look fine to me.
i (and most likely craig as well) will (in true jakarta tradition) pay
attention to reviewing your commits (for the first few at least) so
look out for any replies. :)
- robert
On 11 Feb 2004, at 22:56, Simon Kitching wrote:
> Hi,
>
> As discussed on the user list, there appears to be a need to make calls
> on objects other than the top-of-stack in a manner more flexible than
> the limited SetNextRule and SetRootRule.
>
> Attached is a patch which adds a "targetOffset" attribute to the
> CallMethodRule to indicate which object on the digester stack gets
> invoked. The default value for the offset is 0, which is the old
> behaviour for CallMethodRule (invoke method on top object).
>
> If this is ok, I can commit this myself [first use of new apache commit
> rights - yay!]
>
> Notes:
> (a) the test case uses SetNestedPropertiesRule. When factory methods
> for
> this new rule were added to Digester, the main usage (no constructor
> params) was omitted, so attached is a minor patch to fix this.
>
> (b) several new constructors were added to CallMethodRule each taking
> an
> int targetOffset as a first param. Selecting the target seems the
> *first* thing to do, hence makes sense to me to make it the first
> param..
>
> (c) In CallMethodRule, if target object for call is found to be null, a
> deliberate exception with a useful message is now thrown rather than
> throwing a NullPointerException. I used a SAXException as I couldn't
> see
> anything more appropriate. Alternate suggestions welcome.
>
> (d) I haven't added factory methods on Digester for the new
> CallMethodRule constructors. This usage isn't wildly common, so I'm not
> sure the factory methods are really needed. We can always add them
> later
> anyway.
>
> Regards,
>
> Simon
>
>
> <Digester.java.patch><CallMethodRule.java.patch><CallMethodRuleTestCase
> .java.patch>-----------------------------------------------------------
> ----------
> 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
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 16 Feb 2004, at 21:33, Simon Kitching wrote:
<snip>
> I'm not sure how your "named stacks" idea differs from this. Can you
> describe how it would be used?
the idea is that rather than having just a single object stored for
each name, stacks (identified by name) are used instead. this allows
nested rules to push and pop in additional to allowing flat rules to
communicate by using a single object on the stack.
you'd have signatures something like:
void push(String stackName, Object value)
Object peek(String stackName)
Object pop(String stackName)
this is a more general form which includes the functionality of the
hash map (rules just use a one-deep stack) but also allows more complex
communication.
> And sorry, but I didn't understand your suggestion about "partial
> mapping" at all!
maybe i'll explain it better some other time. (it's a little involved.)
> NB: I still think that a Digester 1.6 release should come before new
> work like this. There's no reason a Digester 1.7 couldn't be done on a
> much shorter cycle than the last one.
i agree
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-02-16 at 11:32, robert burrell donkin wrote:
> (a few possible disconnected observations.)
>
> betwixt is more focussed on automated mapping than digester. betwixt
> bean reading rulesets can be freely mixed with digester rules but it's
> designed (at the moment) around producing a single output bean. one
> concept i'd like to add (one day) is partial mapping - this means that
> xml sub-graph's would be mapped and push the resultant bean onto a pipe
> for processing. i believe that this would be useful in processing
> large, regular xml documents.
>
> i've never really considered about using a hashmap to store betwixt
> results.
>
> for a while i've been thinking about adding named stacks to digester.
> the problem with a hashmap is that it supports well only flat xml.
> named stacks would be a map of stacks which would function equally well
> whether the xml was flat or deep. in the deep case, rules would push
> objects onto stacks with particular names and then pop them. in the
> flat case, they could be used in the way joe's describing. again, this
> is something that i think would be very useful but is probably looking
> for a volunteer to code.
>
> - robert
>
> On 12 Feb 2004, at 00:56, Joe Germuska wrote:
>
> >> I don't really understand how XMLBeanFactory can get away without the
> >> equivalent of Digester's rules, unless the java class names, attribute
> >> names, etc *must* map 1:1 with the xml element/attribute names.
> >
> > Well, XMLBeanFactory isn't promising to be as universally useful at
> > processing XML as Digester, which is how it can get away without
> > requiring rules to be defined.
> >
> > The XMLBeanFactory encounters any number of "bean" elements, which
> > implicitly mean "object-create", but instead of pushing them on a
> > stack, it puts them in a map (effectively, at least). Then it has a
> > standard set-property element, which does what you would expect.
> > However, the contents of set-property can be literal values or
> > references to beans which have already been instantiated.
> >
> > My most common use case for Digester is to instantiate some object and
> > populate it with values. I think it's great that Digester can do a
> > lot more than that, but I feel like I write the same rules over and
> > over, just hooking them to different element names. Of course, if you
> > don't get to define the structure of the XML you are processing,
> > Digester has all the necessary flexibility and such, but since my XML
> > files are usually my own invention, it's no big deal to adapt the XML
> > to whatever tool I'm using.
> >
> > I just found it convenient in this case to be able to use a name
> > rather than a known position on the stack to make an "introduction"
> > between two objects that were instantiated from the XML. That sounded
> > a little like your goal to have rules that reach objects in arbitrary
> > locations on the digester stack, so I piped up.
I think that Joe's suggestion was essentially so that references can be
built between objects other than parent/child.
<doc>
<bean1 id="123">
...
</bean1>
<bean2>
<sibling id="123"/>
....
</bean2>
</doc>
The "sibling" tag results in a bean2 method being invoked with a
*reference* to bean1 as a parameter.
I think this can be fairly easily done with 2 new rules:
StoreNamedReferenceRule(String attrname)
and
NamedReferenceParamRule(String attrname)
The StoreNamedReferenceRule just puts the entry in a HashMap, as Joe
describes. The NamedReferenceParamRule retrieves the referenced object
from the map and puts it into the params array of a CallMethodRule.
One issue is that the HashMap used to store the "named" objects needs to
be accessable to both rules, so really needs to be stored at the
Digester level.
I've been thinking of having a HashMap member on the Digester class,
which can be used by "cooperative" rules like this pair to communicate.
A rule can store into this hashmap a single object keyed by its own
package name; this provides a "namespacing" mechanism that prevents
conflicts over use of this map.
I'm not sure how your "named stacks" idea differs from this. Can you
describe how it would be used?
And sorry, but I didn't understand your suggestion about "partial
mapping" at all!
NB: I still think that a Digester 1.6 release should come before new
work like this. There's no reason a Digester 1.7 couldn't be done on a
much shorter cycle than the last one.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
(a few possible disconnected observations.)
betwixt is more focussed on automated mapping than digester. betwixt
bean reading rulesets can be freely mixed with digester rules but it's
designed (at the moment) around producing a single output bean. one
concept i'd like to add (one day) is partial mapping - this means that
xml sub-graph's would be mapped and push the resultant bean onto a pipe
for processing. i believe that this would be useful in processing
large, regular xml documents.
i've never really considered about using a hashmap to store betwixt
results.
for a while i've been thinking about adding named stacks to digester.
the problem with a hashmap is that it supports well only flat xml.
named stacks would be a map of stacks which would function equally well
whether the xml was flat or deep. in the deep case, rules would push
objects onto stacks with particular names and then pop them. in the
flat case, they could be used in the way joe's describing. again, this
is something that i think would be very useful but is probably looking
for a volunteer to code.
- robert
On 12 Feb 2004, at 00:56, Joe Germuska wrote:
>> I don't really understand how XMLBeanFactory can get away without the
>> equivalent of Digester's rules, unless the java class names, attribute
>> names, etc *must* map 1:1 with the xml element/attribute names.
>
> Well, XMLBeanFactory isn't promising to be as universally useful at
> processing XML as Digester, which is how it can get away without
> requiring rules to be defined.
>
> The XMLBeanFactory encounters any number of "bean" elements, which
> implicitly mean "object-create", but instead of pushing them on a
> stack, it puts them in a map (effectively, at least). Then it has a
> standard set-property element, which does what you would expect.
> However, the contents of set-property can be literal values or
> references to beans which have already been instantiated.
>
> My most common use case for Digester is to instantiate some object and
> populate it with values. I think it's great that Digester can do a
> lot more than that, but I feel like I write the same rules over and
> over, just hooking them to different element names. Of course, if you
> don't get to define the structure of the XML you are processing,
> Digester has all the necessary flexibility and such, but since my XML
> files are usually my own invention, it's no big deal to adapt the XML
> to whatever tool I'm using.
>
> I just found it convenient in this case to be able to use a name
> rather than a known position on the stack to make an "introduction"
> between two objects that were instantiated from the XML. That sounded
> a little like your goal to have rules that reach objects in arbitrary
> locations on the digester stack, so I piped up.
>
> Note that Spring is a whole lot more than just the XMLBeanFactory, but
> I haven't really absorbed all those other layers; I'm not shopping for
> a new web app framework, etc.
>
> Hope that helps.
>
> Joe
> --
> Joe Germuska Joe@Germuska.com http://blog.germuska.com
> "Imagine if every Thursday your shoes exploded if you tied them
> the usual way. This happens to us all the time with computers, and
> nobody thinks of complaining."
> -- Jef Raskin
>
> ---------------------------------------------------------------------
> 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
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by Joe Germuska <Jo...@Germuska.com>.
>I don't really understand how XMLBeanFactory can get away without the
>equivalent of Digester's rules, unless the java class names, attribute
>names, etc *must* map 1:1 with the xml element/attribute names.
Well, XMLBeanFactory isn't promising to be as universally useful at
processing XML as Digester, which is how it can get away without
requiring rules to be defined.
The XMLBeanFactory encounters any number of "bean" elements, which
implicitly mean "object-create", but instead of pushing them on a
stack, it puts them in a map (effectively, at least). Then it has a
standard set-property element, which does what you would expect.
However, the contents of set-property can be literal values or
references to beans which have already been instantiated.
My most common use case for Digester is to instantiate some object
and populate it with values. I think it's great that Digester can do
a lot more than that, but I feel like I write the same rules over and
over, just hooking them to different element names. Of course, if
you don't get to define the structure of the XML you are processing,
Digester has all the necessary flexibility and such, but since my XML
files are usually my own invention, it's no big deal to adapt the XML
to whatever tool I'm using.
I just found it convenient in this case to be able to use a name
rather than a known position on the stack to make an "introduction"
between two objects that were instantiated from the XML. That
sounded a little like your goal to have rules that reach objects in
arbitrary locations on the digester stack, so I piped up.
Note that Spring is a whole lot more than just the XMLBeanFactory,
but I haven't really absorbed all those other layers; I'm not
shopping for a new web app framework, etc.
Hope that helps.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] Enhancing CallMethodRule to take target offset
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-02-12 at 12:07, Joe Germuska wrote:
> Since you've already got working code, take this as just something to
> think about -- but I recently was wishing for a map to complement the
> stack; some place to put objects under names and then have other
> rules refer to those objects by name.
>
> I ended up using the SpringFramework XMLBeanFactory for this case,
> but it may be an idea of interest to other Digester users.
>
> To be honest, besides getting the ability to use objects by name, I
> also appreciated not having to write a digester rules file. (Well, I
> had already written one because I started using Digester until I got
> to the point where the stack didn't really work for me.) Most of the
> time I'm just instantiating objects, setting properties, and relating
> the objects to other, and writing those XML rule files gets kind of
> tedious.
>
> This is not to say that Digester should drop everything to "compete"
> with the XMLBeanFactory. I just thought I'd share an interesting
> alternative solution.
>
> If a Map for Digester would be interesting to other folks, I might
> take a crack at it some time after I get through with my current
> project...
Hi Joe,
This all sounds interesting, but I'm not entirely sure what it means.
When I get a little time I will have a peek at SpringFramework's
XMLBeanFactory. Or if you could summarise where it differs from Digester
that would be great...
I don't really understand how XMLBeanFactory can get away without the
equivalent of Digester's rules, unless the java class names, attribute
names, etc *must* map 1:1 with the xml element/attribute names.
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] Enhancing CallMethodRule to take target offset
Posted by Joe Germuska <Jo...@Germuska.com>.
Since you've already got working code, take this as just something to
think about -- but I recently was wishing for a map to complement the
stack; some place to put objects under names and then have other
rules refer to those objects by name.
I ended up using the SpringFramework XMLBeanFactory for this case,
but it may be an idea of interest to other Digester users.
To be honest, besides getting the ability to use objects by name, I
also appreciated not having to write a digester rules file. (Well, I
had already written one because I started using Digester until I got
to the point where the stack didn't really work for me.) Most of the
time I'm just instantiating objects, setting properties, and relating
the objects to other, and writing those XML rule files gets kind of
tedious.
This is not to say that Digester should drop everything to "compete"
with the XMLBeanFactory. I just thought I'd share an interesting
alternative solution.
If a Map for Digester would be interesting to other folks, I might
take a crack at it some time after I get through with my current
project...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org