DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21603>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21603 Automatic readonly/disabled settings in struts-html Summary: Automatic readonly/disabled settings in struts-html Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We are developing a web application with a number of complex pages and dozens of controls. These controls' readonly status should be set, individually, at runtime. With the current (1.1) struts-html, our pages come out as a repetition of <html:text property="someName" readonly='<%=formBean.isReadonly("someName") %>' styleClass='<%= formBean.isReadonly("someName")?"ReadOnlyClass":"ReadWriteClass" %>' /> With "someName" being replaced each time with the relevant property, of course. Since the application is big, but not huge, this is borderline acceptable to us. Now, of course, we could extend html:text -- and any other specific tag we use -- to deal with it, but I think the correct place for the fix is BaseHandlerTag.java. What I have in mind is an additional attribute to html:form that would define a generic mechanism for setting the control properties, something along the lines of <html:form ... readonlyIndicator="isReadonly" /> Which would then do the equivalent of planting the above code in all the form controls (perhaps with an additional "styleReadonlyClass" property). Note: With CSS2, setting a specific style class for readonly controls should not be necessary, because the selectors can handle it, and in general, I understand that setting styles automagically goes close to UI issues which struts-html may not want to deal with. However, setting the readonly attribute is pure semantics, and even if you don't want to include the styleClass/styleReadonlyClass feature, I would like the automatic readonly part to be considered. And of course, "disabled", although we don't specifically need it, would be a natural candidate for the same treatment. <OT> I thought this was better discussed on the list before I submitted it as a bug, but when I sent it to the list, no one replied... did I do something wrong? </OT> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
