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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
