To add to Martins comments, some shared base fields (attributes) may mean different things for different taglibs, depending on the subclass so those shared fields would need multiple tags for different subclasses.
On the flip side, it would nice not to have to worry about finding all the references to a shared field when updating the docs. -- James Mitchell Web Developer/Struts Evangelist http://www.apache.org/struts/ > -----Original Message----- > From: Erik Hatcher [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 27, 2003 2:23 PM > To: Struts Developers List > Subject: Re: Investigating adding custom ant task to valid > TLD attributes bean mappings > > > On Thursday, February 27, 2003, at 01:57 PM, Martin Cooper wrote: > >> -----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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
