-----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 10:53 AM To: Struts Developers List Subject: Re: Investigating adding custom ant task to valid TLD attributes bean mappings
First of all... why not use XDoclet to generate TLD files in the first place? They you are guaranteed to have valid accurate TLD files.
I don't think this would work as we need it to. Many of the standard
attributes are implemented in base classes, rather than on the tag classes
themselves. That in itself may not be a problem, but not all of the
attributes should be exposed for every tag that extends the base class
(since they're not all valid for all HTML tags, for example).
Ah yes.... its all coming back to me.
My argument here would be that this type of architecture needs refactoring. Having setters in classes that should not be exposed is a Bad Thing, IMHO. And we have the same situation in Ant itself with its tasks, and I'm using XDoclet to process its source code to build documentation:
http://nagoya.apache.org/gump/javadoc/ant/proposal/xdocs/build/docs/ manual/index.html
Would it be possible to control something like that with XDoclet?
Yes, but probably not out of the box with the builtin TLD template, or at least not without some coding changes. I'd recommend, in this case, that setters on the parent classes not be tagged to be tag attributes (@jsp.attribute), but that the subclasses actually override the setters they want to expose and tag them.... and just code it to delegate to the super class (super.setWhatever(whatever)).
So, it could be done, but because of some "funny" stuff Struts has in its class hierarchy it wouldn't be completely straightforward.
If the Struts developers are open to these refactorings, I could give it a try to implement this.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
