commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [digester] Enhancing CallMethodRule to take target offset
Date Sun, 15 Feb 2004 22:32:45 GMT
(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


Mime
View raw message