The reason I implemented it this way is because in many cases, the JSP attribute type in the base class was not String. However in JSP 1.2, the EL expressions are Strings, so the BeanInfo for the JSP tag class has to associate the attributes with String properties. I then made the setter method for the String property convert the value to the correct type and then call the base class setter method.
The only way you could reduce the number of classes would be to find a tag class whose attributes were all String properties. You could then remove the BeanInfo class associated with the EL tag class, remove all the properties in the subclass, and reference the base class setters directly. Frankly, I don't see it being worth it. It's unfortunate that you're using a brain-damaged container, but if it's having problems with this relatively "low-level" aspect of bean management, I wouldn't be surprised if you spend more time trying to figure out hacks to the container than writing productive code. > -----Original Message----- > From: Derek Scherger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 10:20 PM > To: [EMAIL PROTECTED] > Subject: struts-el tags bean info implementation > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
