On Mon, 20 Aug 2001, robert burrell donkin wrote:
>
> On Monday, August 20, 2001, at 04:42 PM, Jason van Zyl wrote:
>
> > On 8/20/01 11:29 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> I have prepared a little test bundle for the problem I've been having
> >> with parsing attributes with the digester:
> >>
> >> http://jakarta.apache.org/~jvanzyl/digester-tester.tgz
> >>
> >> I say possible show stopper because I am still relatively inexperienced
> >> with
> >> the digester but it appears to me that you cannot use the following
> >> sequence
> >> with an error occuring:
> >
> > Correction: you can't use the following sequence more than once without an
> > error occuring. The common morning lack-of-coffee problem.
> >
> >
> >> addMethodCall
> >> addCallParam
> >>
> >> where the parameter to be used is taken from an attribute.
> >>
> >> I have the following little file in the test bundle:
> >>
> >> <a attrA1="attrA1" attrA2="attrA2">
> >> <b attrB1="attrB1" attrB2="attrB2"/>
> >> </a>
> >>
> >> It seems I cannot use that sequence more than once during the whole
> >> process.
> >> I realize in the above example I could use setProperties, but in the
> >> application I'm using this the attribute names don't match any object
> >> properties so I need to use the methodcall/paramcall pairs.
> >>
> >> The test bundle illustrates the problem I believe. If I have set
> >> something
> >> up incorrectly, my apologies.
>
> hi jason
>
> i think you're right - since the attributes are pushed onto the stack, you
> can only use this once per object at the moment. from what i can see
> (maybe craig or scott will come up with something) this is a consequence
> of the design and there isn't an easy patch.
>
That's pretty much it :-(. Let me look into the design question some
more. Also, when finished, I'm going to include something like JVZ's test
case in the unit tests.
> the good thing is that digester is extensible and one easy way round this
> problem would be to create a rule that allowed a property with a different
> name (from the attribute) to be set. if this is what you need, i can easy
> and quickly produce a new rule to do just this.
>
Actually, you don't even need a new rule -- just a BeanInfo class for your
bean that does the appropriate mapping. BeanUtils (which is used
underneath) follows standard Java introspection mechanisms - it does not
assume that the setter for method foo is always named setFoo().
> (if that's not what you need an alternative is to use an objectcreaterule
> and use an implementation of the factory to call a constructor which sets
> the properties you need.)
>
> - robert
>
Craig
