Historically, the Struts developers have been very strict about accepting only W3C standard attributes, and I don't see this changing anytime soon -- it would be somewhat ironic for an open source project to endorse a proprietary single-vendor lock-in by doing something like this :-). I suspect most people who want to use such attributes anyway follow your option (2) but just maintain their own version of the modified tag library.
Since you're talking about a new application here, you should also take a look at using JavaServer Faces (JSF) components for your user interface, instead of the Struts HTML tags. With the standard components you will run into the same issue (they only support standard attributes), but it seems a lot more likely that a community could grow up around custom JSF components that supported these attributes, because they can be used in any JSF compatible environment, not just in applications that use Struts. Craig On Tue, 19 Oct 2004 16:33:09 -0400, Kichline, Don (EM, PTL) <[EMAIL PROTECTED]> wrote: > 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]
