On Wednesday, December 5, 2001, at 06:02 PM, Craig R. McClanahan wrote:
<snip>
> The key is that the third argument to addSetNext() has to match the
> method's signature, because this is what is used to do the reflection
> lookup. The object on the top of the stack (a StandardHost in the example
> above) need only be assignment-compatible with that signature for this to
> work.
>
> Is this the case you're talking about?
no. at the moment, you have to specify the third parameter in order to
make the digestion work.
this isn't too much of limitation - once you know how to do it, it's just
a bit of extra typing.
where it becomes a bit more restrictive is when you use a general matching
rule (like '*'). for example you might have a naming scheme where all
child objects are added by calling addChild on the parent. you can write a
single general rule only when either each class has an addChild method
that takes a specific interface (xxx.yyy.zzz.Child, say). In this case,
you can use something like
digester.addSetNext("*", "addChild", "xxx.yyy.zzz.Child);
you can also write a single general rule if every object has an exactly
matching addChild method. In this case you can use
digester.addSetNext("*", "addChild");
if your object model doesn't follow one of these two patterns, then even
if each object has a method with the right name with an
assignment-compatible parameter then the digestion won't work.
i'm not suggesting that this is killing functionality but it'd be nice to
have if there was an appropriate method finder available...
>> jason came across a similar issue with his automatic mapper but it meant
>> that he ended up using indexed properties rather than calling an addXXX
>> method for children (since beanutils will find an indexed property but
>> not
>> a name single parameter method). unfortunately, using indexed properties
>> means that writing a digester-powered version is not realistic.
>>
>> i was wondering whether code to do this kind of single parameter method
>> finding would fit as part of propertyutils.
>>
>
> PropertyUtils itself is focused only on finding property getters and
> setters. But some general utility classes to make some of the really
> strange things with Java reflection easier to use (for example, finding a
> "compatible" Method rather than just an exact-match Method) would
> certainly fit into the overall "beanutils" package.
yes, you're right - PropertyUtils does seem like the wrong place. it does
have a number of private utility methods which might be useful, i suppose
that these could be moved out or given public access, though.
- robert
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|