struts-el tags bean info implementation

[Derek Scherger <de...@echologic.com>]

I have a question about the current (beaninfo) implementation of the el tags, hopefully 
this is the right place to be asking!

Rather than using an additional beaninfo class for each ELFooTag class would it not be 
simpler for the ELFooTag classes to override the setFoo methods of the associated FooTag 
class they are extending?

i.e.

in FooTag we have an attribute foo with setFoo and getFoo methods

currently in ELFooTag we have an additional attribute fooExpr with setFooExpr and 
getFooExpr methods and an associated beaninfo class to map calls to setFoo into calls to 
setFooExpr

alternatively in ELFooTag we could include fooExpr as it currently exists but simply 
override setFoo so that it instead sets fooExpr and then rely on the current 
evaluateExpressions method to compute the current value and call super.setFoo() with the 
evaluated value.

I ask for two reasons: First, the alternative approach seems somewhat simpler (i.e. 50% 
fewer classes with the removal of the beaninfo's). Second, because I'm using a broken app 
server (not by choice) that doesn't process the beaninfo classes properly (if it processes 
them at all) and the alternative (overridden method) implementation does seem to work.

I've hacked in overriding setFoo methods and associated super.setFoo calls in 
evaluateExpressions in a couple of test cases and it seems to work in my broken app server 
at least.

Thanks for any info!
-- 
Cheers,
Derek

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org