commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [digester] CallMethodRule order [bug12997] attn: Emmanuel, Craig
Date Sat, 28 Feb 2004 17:42:51 GMT
Quoting robert burrell donkin <>:

> On 26 Feb 2004, at 15:15, Simon Kitching wrote:
> <snip>
> > I don't really understand Craig's comments re "hierarchical
> > structure that is isomorphic to a tree of beans that is being created".
> the association graph for a bean is often a tree with secondary beans 
> being properties from a primary bean. the elements in xml (ignoring 
> ID/IDREFs) also form a tree. a very common use case is when the element 
> -> bean transformation is an isomorphism. in other words, when there is 
> a one-to-one correspondence between elements and beans.
> i think maybe an example would help (some properties suppressed):
> AlphaBean
> 	getBeta:BetaBean
> 	getGamma:GammaBean
> GammaBean
> 	getEpsilon:EpsilonBean
> and this kind of thing:
> <alpha>
> 	<beta/>
> 	<gamma>
> 		<epsilon/>
> 	</gamma>
> </alpha>
> i think that craig's point is that CallMethodRule is aimed at this very 
> common use case and that it'd be better to add another rule that 
> performs another function for other use cases. this has the advantage 
> of reducing the complexity of the code and also makes it easier for the 
> user to find the functionality they require.
> (hopefully he'll jump in about now if i've misrepresented his opinions 
> ;)

Nope :-).  You've got it just right.  In fact, the original motivation for
creating Digester in the first place was exactly this sort of scenario, for
applications like Struts and Tomcat that assemble graphs of beans that
generally  have an isomorphic structure to the nesting of elements in the XML
configuration documents.

> - robert


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message