You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2003/06/25 04:41:10 UTC

DO NOT REPLY [Bug 18015] - New custom tag to write forms' properties

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=18015>.
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=18015

New <html:label> custom tag to write forms' properties

dgraham@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[RFE] - A html:label custom |New <html:label> custom tag
                   |tag to write forms'         |to write forms' properties
                   |properties                  |



------- Additional Comments From dgraham@apache.org  2003-06-25 02:41 -------
The idea is good but there are a couple of things about the implementation that 
bother me.  Forcing people to use specific message resources keys is not a good 
idea because they may have used that key for something else.  The "key" 
attribute should be a free form key into the resources that grabs the label 
text.  Then a "property" attribute would define what form field the label 
applies to (property may not be the best term but it matches the current Struts 
convention).

It's not intuitive that styleClass means required.  The styleClass attribute 
should be renamed requiredStyleClass and errorClass should be renamed 
errorStyleClass to match the Struts convention.  The styles have hardcoded 
defaults in the tag ("required" for requiredStyleClass and "error" for 
errorStyleClass) that need to be removed (the user might have defined an "error" 
style that they're quite fond of but don't want to use with LabelTag).  If the 
user doesn't specify a class in the tag's attribute it shouldn't use one.  

Alternatively, I've found that a good way of allowing an application wide 
default (to relieve the burden of specifying the style each time) without 
hardcoding it in the tag is to allow the user to specify an application context 
parameter defined in web.xml.  If not specified in the tag's attribute, the 
value is looked up in the context parameter.  If not found there, no style is 
rendered.  The parameter name to lookup in the context would be org.apache.
struts.taglib.html.LabelTag.requiredStyleClass.

Tag's should not presume to know what user's defaults should be.  I would 
certainly use this tag if were included with Struts with the above 
modifications.

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org