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]

Reply via email to