Firstly on a general note, if its new development, then IMO it would be better to use the latest Struts 1.2.4 release.
More specifically on adding additional attributes to Struts tags, I recently refactored some of the HTML tags (specifically all those that derive from BaseHandlerTag) and added the prepareOtherAttributes(StringBuffer) method which gets called just before the closing tag element and gives you somewhere to put the rendering of additional attributes. So for example if you wanted to add the "wrap" attribute to the TextareaTag, then you would simply have to do the following.... public class CustomTextareaTag extends TextareaTag { protected String wrap; public void setWrap(String wrap) { this.wrap = wrap; } public String getWrap() { return wrap; } protected void prepareOtherAttributes(StringBuffer handlers) { prepareAttribute(handlers, "wrap", getWrap()); } public void release() { super.release(); wrap = null; } } You would also need to either modify the struts-html.tld to use your custom implementation and add the "wrap" attribute, or set up your own tld for this tag. This is available either in the nightly build or in the recently posted Struts 1.2.5 Test Build which can be found here: http://svn.apache.org/dist/struts/v1.2.5/ Alternatively, there are a couple of outstanding enhancement requests for mechanisms which facilitate additional attributes. To date nothing has been done about them but maybe they would suit your needs and you could contribute ideas/patches to those bugs: 1) Bug 1598 http://issues.apache.org/bugzilla/show_bug.cgi?id=1598 This bug suggests tackling this by having some kind of "other" attribute which just gets passed through unchanged: I imagine whats being proposed there would be, using the "wrap" example, something like the following.. <html:textarea property="...." other="wrap='off'"/> 2) Bug 29379 http://issues.apache.org/bugzilla/show_bug.cgi?id=29379 This bug requests support of JSTL's param tag - personally I don't see how using JSTL's param tag would work, but maybe a new <html:param> tag could do this and, using the "wrap" example again would work something like the following... <html:textarea property="...." > <html:param name="wrap" value="off"/> </html:textarea> The way I can think of making this work would involve more re-factoring of many of the tags though. Having said all that about the *bugs* though, the problem you'll face will be getting anyone to implement your changes and you may go to the trouble of developing patches that just get ignored. Niall ----- Original Message ----- From: "Kichline, Don (EM, PTL)" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, October 19, 2004 9:33 PM Subject: non-standard attributes in taglib We have a web based application that is a work in progress. Because our company mandates that IE be used, certain aspects of microsoft's non-standard extensions have been utilized in some of our pages. All new screens in our system will be developed using Struts 1.1. We have however run into one small problem. The HTML taglib does not take non-standard attributes. At least that I can see. So we have one of a number of choices to make: 1. Remove use of non-standard attributes (this one is not likely) 2. Modify the html tag lib to support generic non-standard attributes and submit it 2a. Submissions are accepted (we are fine then) 2b. Submissions are rejected (we are back where we started) 3. Do not use the html tag lib (we don't want to do this for obvious reasons) 4. Dynamically add the attributes to the elements in an onload javascript function (This is what we are currently doing to work around this problem, not intended as a long term solution.) Ignoring solution #1, what do people think we should do with this? Thanks, Don Kichline --------------------------------------------------------------------- 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]