commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: Digester wildcard question
Date Tue, 21 Jun 2005 14:25:29 GMT
Simon Kitching wrote:
> I'm puzzled too. It's not terribly elegant but I don't see why it won't
> work in your case.

What?!?  Not elegant?!??  Why you little... eh, maybe your right, never 
mind ;)

> Rather than distort your design, I would suggest either:
> 
> (a)
> Create your own Rule class based on the source for
> BeanPropertySetterRule, but replacing all of the method lookup stuff
> with a simple:
>   Method m = Config.class.getMethod(xmlElementName);
>   m.invoke(null, bodyText);
> All your config methods seem to take strings so you don't need to worry
> about type-conversion.

I thought of that too... ironically, talking about elegance, I thought 
that was less elegant than extending an existing class that already did 
99% of what I wanted :)

> (b)
> Turn your config object into a singleton. Instead of using
> ObjectCreateRule, use FactoryCreateRule with a custom ObjectFactory
> which simply returns the singleton object. It's still a change to your
> design but not so radical.

I think that will actually put a bit more restrictions on the bean than 
I'd like, although I certainly see your point.

I think because of what I'm really trying to do, I'm simply going to 
document the fact that the setters of the bean must be non-static.  The 
getters can still be static, which is really the more important 
consideration, and that's what I'll do for the sample bean I am doing. 
In the end it will be a developers' choice, not mine, but as long as 
they know this "limitation", minor as it is, I think that is OK.  It 
could even be argued it isn't really a limitation anyway, just a point 
to document, and I think that's where I'm coming down on it in the end.

Thanks for all your help Simon, it has been absolutely invaluable!  I've 
learned more about Digester in the last few hours than in all the time 
I've used it before :)

Frank


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message