(Digester) More flexible mothod matching [Was Re: [BeanUtils] invokeExactMethod() --> invokeMethod() ?]

[robert burrell donkin <ro...@mac.com>]

i've now committed changes to SetNextRule, SetRootRule and SetTopRule that 
allow the user to choose whether to use the more flexible method matching 
MethodUtils.invokeMethod or the original, more precise 
MethodUtils.invokeExactMethod. i've made the more flexible behaviour the 
default since i think that it's more intuitive. this choice may break a 
very small amount of existing code but this can be fixed by enabling exact 
matches for that rule.

hopefully, these changes do pretty much want Bart wanted.

- robert


On Tuesday, February 12, 2002, at 11:22 PM, Bart Guijt wrote:

> From: "robert burrell donkin" <ro...@mac.com>
>> On Monday, February 11, 2002, at 09:29 PM, Bart Guijt wrote:
>>> Right now we need to use this particular feature using the commons
>>> Digester.
>>
>> do you have a concrete example? i might be able to suggest how you could
>> achieve what you want without requiring this change.
>
> After reviewing and tweaking our digester rules setup code, we were able 
> to
> use umodified digester/beanutils packages. So after all, the BeanUtils
> changes seem to be unnecessary.
>
> The problem was creating digester rules for XML like this:
>
> <a>
>   <b>
>     <b>
>       <b />
>       <b />
>     </b>
>     <b />
>   </b>
> </a>
>
> Here you see a tree of 'b' elements inside of 'a'. We want to translate 
> this
> into an objecttree where each element contains a list of its children. The
> Digester provides the 'addSetNextRule' method to achieve this.
>
> If you have a rule matching each '*/b' element you can only specify one
> class as the parent type (either for 'a' or 'b'). We first tried to have
> both 'a' and 'b' classes implement the same interface. This didn't work, 
> the
> beanutils package threw InvokationTargetExceptions (or something like 
> that).
> We then tried to create two setNextRules, one matching the 'a/b' element 
> and
> another matching the '*/b' elements, using two separate parent types far 
> 'a'
> and 'b'. This solved the problem.
>
>>> 2. I already took a leap to implement a method
>>> 'getMatchingPublicMethod(Class clazz, String methodName, Class[]
>>> paramTypes)' which returns the correct method and is called from the
>>> 'getAccessibleMethodFromInterfaceNest()' method. This seems to work, aka
>>> the tests don't fail. Since this change defuses the
> 'invoke*Exact*Method(
>>> )' semantics, is this the right solution? It seems either the methods
>>> need to be renamed or the Digester code needs to be adjusted to call a
>>> new 'invokeMethod()'.
>>
>> i'm a bit confused by this paragraph. if you're proposing a patch then i'
>> d
>> find your logic easier to follow if you could supply a cvs diff -u.
>
> Re-reading this paragraph confuses me as well :-)
>
> Anyway, thanks for your attention!
>
>> - robert
>
> Bart Guijt
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: (Digester) More flexible mothod matching [Was Re: [BeanUtils] invokeExactMethod() --> invokeMethod() ?]

[Bart Guijt <b....@chello.nl>]

Cool!

I'll check it out and see if I can cut some from the Digester rules setup!

Thanks very much,

BG

----- Original Message -----
From: "robert burrell donkin" <ro...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Bart Guijt" <b....@chello.nl>
Sent: Wednesday, March 20, 2002 11:49 PM
Subject: (Digester) More flexible mothod matching [Was Re: [BeanUtils]
invokeExactMethod() --> invokeMethod() ?]


> i've now committed changes to SetNextRule, SetRootRule and SetTopRule that
> allow the user to choose whether to use the more flexible method matching
> MethodUtils.invokeMethod or the original, more precise
> MethodUtils.invokeExactMethod. i've made the more flexible behaviour the
> default since i think that it's more intuitive. this choice may break a
> very small amount of existing code but this can be fixed by enabling exact
> matches for that rule.
>
> hopefully, these changes do pretty much want Bart wanted.
>
> - robert
>
>
> On Tuesday, February 12, 2002, at 11:22 PM, Bart Guijt wrote:
>
> > From: "robert burrell donkin" <ro...@mac.com>
> >> On Monday, February 11, 2002, at 09:29 PM, Bart Guijt wrote:
> >>> Right now we need to use this particular feature using the commons
> >>> Digester.
> >>
> >> do you have a concrete example? i might be able to suggest how you
could
> >> achieve what you want without requiring this change.
> >
> > After reviewing and tweaking our digester rules setup code, we were able
> > to
> > use umodified digester/beanutils packages. So after all, the BeanUtils
> > changes seem to be unnecessary.
> >
> > The problem was creating digester rules for XML like this:
> >
> > <a>
> >   <b>
> >     <b>
> >       <b />
> >       <b />
> >     </b>
> >     <b />
> >   </b>
> > </a>
> >
> > Here you see a tree of 'b' elements inside of 'a'. We want to translate
> > this
> > into an objecttree where each element contains a list of its children.
The
> > Digester provides the 'addSetNextRule' method to achieve this.
> >
> > If you have a rule matching each '*/b' element you can only specify one
> > class as the parent type (either for 'a' or 'b'). We first tried to have
> > both 'a' and 'b' classes implement the same interface. This didn't work,
> > the
> > beanutils package threw InvokationTargetExceptions (or something like
> > that).
> > We then tried to create two setNextRules, one matching the 'a/b' element
> > and
> > another matching the '*/b' elements, using two separate parent types far
> > 'a'
> > and 'b'. This solved the problem.
> >
> >>> 2. I already took a leap to implement a method
> >>> 'getMatchingPublicMethod(Class clazz, String methodName, Class[]
> >>> paramTypes)' which returns the correct method and is called from the
> >>> 'getAccessibleMethodFromInterfaceNest()' method. This seems to work,
aka
> >>> the tests don't fail. Since this change defuses the
> > 'invoke*Exact*Method(
> >>> )' semantics, is this the right solution? It seems either the methods
> >>> need to be renamed or the Digester code needs to be adjusted to call a
> >>> new 'invokeMethod()'.
> >>
> >> i'm a bit confused by this paragraph. if you're proposing a patch then
i'
> >> d
> >> find your logic easier to follow if you could supply a cvs diff -u.
> >
> > Re-reading this paragraph confuses me as well :-)
> >
> > Anyway, thanks for your attention!
> >
> >> - robert
> >
> > Bart Guijt
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.
> > org>
> > For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.
> > org>
> >
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>