Re: LabelTag
Erik, You might want to have a look at the struts-layout taglib hosted at http://struts.application-servers.com This opens source library implements (nearly) all the functionality you described here, and much more ! If you intend to share your code, I'm very interesting in the part checking if a field is required in the validator resources. Regards, Jean-Noel At 02:52 15/10/2002, you wrote: I implemented something that I think is relatively slick today, so I thought I'd share the idea. First, a change was requested to suffix all our field labels with colons. We already had this structure: thbean:message key=SomeForm.someField//th tdhtml:text property=someField//td I created a LabelTag taglib that (currently, but not necessary) subclasses MessageTag. It, of course, satisfies the request to suffix with a colon such that our message resources (now in the database) are not changed, and the JSP does not have colons. But, I figured why stop there, so I dug through ValidatorResources and added in an asterisk if the field is required, and then dug through ActionErrors and turned the field red (using CSS classes and a span) if the field was in error. This is a feature I've been thinking of for a while, and I'm sure others have implemented similar features, but its such a big enhancement that I felt like sharing it! I'm not sure if this is worthy of making more generic and contributing though. Thoughts? Its dependent on your forms subclassing ValidatorForm and validation.xml be used appropriately, and it also relies on field labels adhering to the form name.field name syntax and be stored in the message resources. Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
Martin Cooper wrote: I like the idea. I do see a couple of problems, however. * You are presumably defining the juxtaposition of the label, the colon, the asterisk, and the input field, in the tag itself. This, I think, would be rather specific to the layout you have in mind. Yes. We have this layout: Some Field: My label tag only creates the Some Field:, not the input box, so it does presume it comes to the left or above. Our app. has no I18N requirements at this point. * The use of a trailing colon is very much locale-dependent. In some languages (e.g. Finnish), the use of a trailing colon actually changes the meaning of the text before it. In such cases, a somewhat different layout may be desired. Interesting. What does it change about the meaning of the text, just out of curiosity? Certainly, neither of these is insurmountable. In fact, if they could be resolved in such a way that the tag supports full i18n and is still easy to use, this would be a very handy tag. I'll paste the relevant code snippet in reply to the next message, and you folks can do what you want with it. I certainly won't have the time or knowledge to make it more generic than it already is, except to perhaps have some indirection on what to wrap around the message (its a span now, with * and style class to affect the display). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
Jean-Noel Ribette wrote:
Erik,
You might want to have a look at the struts-layout taglib hosted at
http://struts.application-servers.com
This opens source library implements (nearly) all the functionality you
described here, and much more !
Cool - I've looked at that library before but had forgotten about it.
For some reason I like to implement this stuff myself though :) Good
stuff though - we don't really have all those layout needs so that
framework might be a bit much for us.
If you intend to share your code, I'm very interesting in the part
checking if a field is required in the validator resources.
Here's the relevant snipped from doStartTag():
// Look up this key to see if its a field of the current form
boolean requiredField = false;
boolean validationError = false;
ValidatorResources resources = (ValidatorResources)
pageContext.getServletContext().getAttribute(ValidatorPlugIn.VALIDATOR_KEY);
ActionMapping mapping = (ActionMapping)
pageContext.getAttribute(Globals.MAPPING_KEY, PageContext.REQUEST_SCOPE);
Locale locale = (Locale)
pageContext.getAttribute(Action.LOCALE_KEY, PageContext.SESSION_SCOPE);
// this is where there is some specific stuff
// with our key conventions: SomeForm.someField would the key
String formName = mapping.getAttribute();
String fieldName = key.substring(formName.length() + 1);
Form form = resources.get(locale, formName);
if (form != null) {
Field field = (Field) form.getFieldMap().get(fieldName);
if (field != null) {
if (field.isDependency(required)) {
requiredField = true;
}
}
}
// see if field is in error
ActionErrors errors = (ActionErrors)
pageContext.getAttribute(Action.ERROR_KEY, PageContext.REQUEST_SCOPE);
if (errors != null) {
Iterator errorIterator = errors.get(fieldName);
if (errorIterator.hasNext()) {
validationError = true;
}
}
// lookup of message removed, same as MessageTag here
message = span class=\ + (validationError ? labelerror :
label) + \ + message + (requiredField ? * : ) + :/span;
If there is room for improvement here, by all means let me know. I
don't suppose there is much way to improve the performance of this,
since its all pretty random access quick code, but smells like a bit
much to do so many times in one page.
Again, if the requirement ever changes to make the span, *, or style
class different we can easily make that part dynamic based on some site
configuration or other message resource lookups. And of course its all
in one place so we can affect the whole site at once. We're agile, ya
see, and don't do more than necessary, but set it up so that we could
easily extend if desired later :)
Again, let me know if anything I've code above is wrong, brittle, or not
as good as it could get. And feel free to incorporate this wherever you
like.
Erik
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
Ted Husted wrote: Maybe we could use this as the basis for a how to extend taglibs bit for the user guide. Yeah, except that my extension of MessageTag is only temporary, unless we see a need to support all the other bean:message attributes. Currently we only are using 'key', and thats the only one I exposed in the TLD. But certainly it could be made to expose all attributes and would use them appropriately currently. What a pain it is to cut-and-paste the TLD stuff though (actually thats why I only exposed the 'key' property - I use XDoclet to build our TLD from @tags). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
edgar wrote:
It would really be nice :-) to add object orientation to the tld as the
amount of time spent debugging missing / incorrect tld's is larger than
it should be. Also, the ability to specify default values would be nice
as well.
My idea would be something like
tag
nametagextendingtag/name
tagclassorg.apache.struts.taglib.TagExtendingTag/tagclass
bodycontentJSP/bodycontent
attribute
nameproperty/name
requiredfalse/required
rtexprvaluetrue/rtexprvalue
defaultmydefault/default
/attribute
includeattibutes[tldfilename]originaltagname/includeattibutes
/tag
XDoclet really makes childs play out of dealing with the headaches of
deployment descriptors. Here's what my LabelTag looks like:
/**
* @jsp.tag name=label bodycontent=empty
*/
public class LabelTag extends MessageTag {
public int doStartTag() throws JspException {
// ...
}
/**
* @jsp.attribute required=true
*/
public void setKey(String key) {
super.setKey(key);
}
}
The TLD entry is generated automatically for me. Inheritance would be
nice, and it would work if I put @tags on MessageTag and used Struts
source code in my generation too, but thats not my source.
I do highly encourage the Struts committers to use XDoclet for TLD and
documentation generation (but I guess if it ain't broke, don't fix it, eh?).
Erik
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
The number of missing attributes in the tag libraries is large enough to consider a change, especially since writing tag libraries is one of the most pleasurable parts of what we do ;-). Edgar. I do highly encourage the Struts committers to use XDoclet for TLD and documentation generation (but I guess if it ain't broke, don't fix it, eh?). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
Unfortunately, it's not that simple with the Struts tags. Many of the tags extend a base class which defines a number of common attributes. However, just because the code for an attribute is available does *not* mean that it should be exposed for every tag that extends the base class. A case in point is the HTML taglib. Which attributes are exposed for a particular tag is dependent upon the HTML 4.01 spec. In the implementation, it is very convenient to have several base classes which cover the large majority of attributes. However, there are some tags which extend the base classes, but which do not expose all of the attributes, so that they conform to the spec. Now, if we could get XDoclet to handle that... ;-) -- Martin Cooper -Original Message- From: Edgar Dollin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 7:22 AM To: 'Struts Developers List' Subject: RE: LabelTag The number of missing attributes in the tag libraries is large enough to consider a change, especially since writing tag libraries is one of the most pleasurable parts of what we do ;-). Edgar. I do highly encourage the Struts committers to use XDoclet for TLD and documentation generation (but I guess if it ain't broke, don't fix it, eh?). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
My apologies for not understanding this particular issue. There are some liberties that by necessity need to be taken with the tag library definitions, i.e. styleClass for class. I don't understand why someone would care if there are 'excess' tags in the tag library. I would never consider looking at the tag library to determine the availability of a tag and if someone choose to use an attribute that is not supposed to be in the html, html will (is supposed to) ignore it. My apologies in advance to the original struts designers as I assume they had there reasons for the design choices. But, I have issues with the design of the 'html' equivalent struts tags. They are not constructed the way the html specification is designed. For example in html there is one tag for input with multiple types, in struts there are multiple tags (all of which require tld entries). If the struts tags were constructed in a fashion which matched the html spec, then many of the issues with excess tags would go away. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 10:43 AM To: 'Struts Developers List' Subject: RE: LabelTag Unfortunately, it's not that simple with the Struts tags. Many of the tags extend a base class which defines a number of common attributes. However, just because the code for an attribute is available does *not* mean that it should be exposed for every tag that extends the base class. A case in point is the HTML taglib. Which attributes are exposed for a particular tag is dependent upon the HTML 4.01 spec. In the implementation, it is very convenient to have several base classes which cover the large majority of attributes. However, there are some tags which extend the base classes, but which do not expose all of the attributes, so that they conform to the spec. Now, if we could get XDoclet to handle that... ;-) -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
I would argue (mildly) that the design is a bit wrong if the base class attributes are hidden from subclass tags (although I just did something similar, didn't I? :), but either way its not a big deal since Struts already has a system in place to generate docs and TLD's, although its separate from the source. I think the source is the right place for docs and metadata for taglibs, hence my affection for XDoclet in this case :) Erik Martin Cooper wrote: Unfortunately, it's not that simple with the Struts tags. Many of the tags extend a base class which defines a number of common attributes. However, just because the code for an attribute is available does *not* mean that it should be exposed for every tag that extends the base class. A case in point is the HTML taglib. Which attributes are exposed for a particular tag is dependent upon the HTML 4.01 spec. In the implementation, it is very convenient to have several base classes which cover the large majority of attributes. However, there are some tags which extend the base classes, but which do not expose all of the attributes, so that they conform to the spec. Now, if we could get XDoclet to handle that... ;-) -- Martin Cooper -Original Message- From: Edgar Dollin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 7:22 AM To: 'Struts Developers List' Subject: RE: LabelTag The number of missing attributes in the tag libraries is large enough to consider a change, especially since writing tag libraries is one of the most pleasurable parts of what we do ;-). Edgar. I do highly encourage the Struts committers to use XDoclet for TLD and documentation generation (but I guess if it ain't broke, don't fix it, eh?). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
On Tue, 15 Oct 2002, edgar wrote: Date: Tue, 15 Oct 2002 09:10:32 -0400 From: edgar [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: LabelTag It would really be nice :-) to add object orientation to the tld as the amount of time spent debugging missing / incorrect tld's is larger than it should be. Also, the ability to specify default values would be nice as well. My idea would be something like tag nametagextendingtag/name tagclassorg.apache.struts.taglib.TagExtendingTag/tagclass bodycontentJSP/bodycontent attribute nameproperty/name requiredfalse/required rtexprvaluetrue/rtexprvalue defaultmydefault/default /attribute includeattibutes[tldfilename]originaltagname/includeattibutes /tag Of course, this isn't something that Struts can change :-). Please submit suggested changes to the JSP spec to the appropriate email address for consideration: [EMAIL PROTECTED] Edgar Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
On Tue, 15 Oct 2002, Edgar Dollin wrote: Date: Tue, 15 Oct 2002 12:12:12 -0400 From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: LabelTag My apologies for not understanding this particular issue. There are some liberties that by necessity need to be taken with the tag library definitions, i.e. styleClass for class. I don't understand why someone would care if there are 'excess' tags in the tag library. I would never consider looking at the tag library to determine the availability of a tag and if someone choose to use an attribute that is not supposed to be in the html, html will (is supposed to) ignore it. I think XDoclet is cool, but the issue here is not extra tags -- it's extra attributes. One of our primary design principles is that Struts tags would only contain attributes that correspond to valid attribute names (for that particular element) in HTML/4.01 -- whether the browser ignores extra ones or not is irrelevant, since our goal is to not emit invalid HTML. My apologies in advance to the original struts designers as I assume they had there reasons for the design choices. But, I have issues with the design of the 'html' equivalent struts tags. They are not constructed the way the html specification is designed. For example in html there is one tag for input with multiple types, in struts there are multiple tags (all of which require tld entries). If the struts tags were constructed in a fashion which matched the html spec, then many of the issues with excess tags would go away. Can you provide a specific example of what you mean by constructed in a fashion which matched the HTML spec and how you would suggest improving them? Keep in mind (per my preceding response) that we don't have the ability to modify the syntax of a TLD file, since that is defined by the JSP Specification. All we can possibly do is refactor the underlying base classes. And, even that effort seems less useful to me, if we really do migrate towards using JSTL and JavaServer Faces in future versions of Struts. Of course, that shouldn't stop anyone that wants to actually do the work (imho after 1.1 final). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I think your suggestion on having one struts tag that emits any input type (like the html spec) is very flawed. Consider how huge that one tag would be if it knew how to output text, textarea, radio, checkbox, submit, and password fields. Each of the struts input tags have features unique to them and deserve to be separate. Also, the struts tags need attributes for html AND beans, properties, etc. That's why you see attributes like styleClass instead of class. Who cares how many tld entries there are? This is a non-issue, especially in servlet 2.3 where you don't ever have to see the tlds. Even without 2.3, it's trivial to put struts-*.tld files in your /WEB-INF directory. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: LabelTag Date: Tue, 15 Oct 2002 09:28:50 -0700 (PDT) On Tue, 15 Oct 2002, Edgar Dollin wrote: Date: Tue, 15 Oct 2002 12:12:12 -0400 From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: LabelTag My apologies for not understanding this particular issue. There are some liberties that by necessity need to be taken with the tag library definitions, i.e. styleClass for class. I don't understand why someone would care if there are 'excess' tags in the tag library. I would never consider looking at the tag library to determine the availability of a tag and if someone choose to use an attribute that is not supposed to be in the html, html will (is supposed to) ignore it. I think XDoclet is cool, but the issue here is not extra tags -- it's extra attributes. One of our primary design principles is that Struts tags would only contain attributes that correspond to valid attribute names (for that particular element) in HTML/4.01 -- whether the browser ignores extra ones or not is irrelevant, since our goal is to not emit invalid HTML. My apologies in advance to the original struts designers as I assume they had there reasons for the design choices. But, I have issues with the design of the 'html' equivalent struts tags. They are not constructed the way the html specification is designed. For example in html there is one tag for input with multiple types, in struts there are multiple tags (all of which require tld entries). If the struts tags were constructed in a fashion which matched the html spec, then many of the issues with excess tags would go away. Can you provide a specific example of what you mean by constructed in a fashion which matched the HTML spec and how you would suggest improving them? Keep in mind (per my preceding response) that we don't have the ability to modify the syntax of a TLD file, since that is defined by the JSP Specification. All we can possibly do is refactor the underlying base classes. And, even that effort seems less useful to me, if we really do migrate towards using JSTL and JavaServer Faces in future versions of Struts. Of course, that shouldn't stop anyone that wants to actually do the work (imho after 1.1 final). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I think XDoclet is cool, but the issue here is not extra tags -- it's extra attributes. One of our primary design principles is that Struts tags would only contain attributes that correspond to valid attribute names (for that particular element) in HTML/4.01 -- whether the browser ignores extra ones or not is irrelevant, since our goal is to not emit invalid HTML. Not to be picky, but this is the HTML author inserting extra tags, not struts. Can you provide a specific example of what you mean by constructed in a fashion which matched the HTML spec and how you would suggest improving them? Keep in mind (per my preceding response) that we don't have the ability to modify the syntax of a TLD file, since that is defined by the JSP Specification. All we can possibly do is refactor the underlying base classes. The structure of the HTML spec is an object oriented document and if the elements and attributes were emitted in a similar fashion i.e. !ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector -- !ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- nameCDATA #IMPLIED -- field name -- sizeNUMBER #IMPLIED -- rows visible -- multiple(multiple) #IMPLIED -- default is single selection -- disabled(disabled) #IMPLIED -- unavailable in this context -- tabindexNUMBER #IMPLIED -- position in tabbing order -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onchange%Script; #IMPLIED -- the element value was changed -- one might have designed the following objects emitCoreattrs / emitI18n / emitEvents as java objects emitName as a object. In some ways struts takes shortcuts i.e. in the events it just always outputs all the events. In other ways it has too many objects, i.e. TextTag, HiddenTag instead of InputTag with type=text/hidden. Also, IMHO nesting should be an attribute of each base tag rather than a trivial object extending each of the base tags. The result is you end up with large unwieldy and buggy tld's. Of course if this is obsolete, then my apologies for wasting everyone's time :-(. Edgar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I guess we have a difference of opinion. I care about the tld's because they take time getting them correct and I have an explosion of entries in my projects. Also, the struts tld's (at least in 1.0.2) are missing attributes. HTML and all the other languages we use are hard enough to learn and get effective with, using consistent syntax much less inconsistent syntax. Yes there are differences and the class would be slightly larger than normal but it wouldn't be unmanageable and with clever syntactic analysis would not be much larger. After all the browser has to be built to handle the input html object. Thanks for your commentary. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 12:50 PM To: [EMAIL PROTECTED] Subject: RE: LabelTag I think your suggestion on having one struts tag that emits any input type (like the html spec) is very flawed. Consider how huge that one tag would be if it knew how to output text, textarea, radio, checkbox, submit, and password fields. Each of the struts input tags have features unique to them and deserve to be separate. Also, the struts tags need attributes for html AND beans, properties, etc. That's why you see attributes like styleClass instead of class. Who cares how many tld entries there are? This is a non-issue, especially in servlet 2.3 where you don't ever have to see the tlds. Even without 2.3, it's trivial to put struts-*.tld files in your /WEB-INF directory. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: LabelTag
10/15/2002 1:04:54 PM, Edgar Dollin [EMAIL PROTECTED] wrote: Of course if this is obsolete, then my apologies for wasting everyone's time :-(. Whether or not these tags become obsolete is a matter of whether anyone wants to continue using and improving them. Right now, a lot of people seem interested in minimizing the Struts taglibs and maximizing use of the JSTL and (eventualy) JSF. But both of these technologies are very young, and no one can say how people will feel once the blush is off the rose. I don't believe anyone would veto further work on the Struts tags. (And even if we did, the Apache License allows any one to pickup where we left off in another CVS.) All the Comitters are individuals and choose for themselves what they want to work on. But just because some people decide to work on one thing does not mean that other people cannot work on something else. It is often a waste of time to talk about what other people should do, since most of us already have plenty on our plates. But it is not a waste of time to talk about things you might do yourself. -Ted.y -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
On Tue, 15 Oct 2002, Edgar Dollin wrote: Date: Tue, 15 Oct 2002 13:24:56 -0400 From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: LabelTag I guess we have a difference of opinion. I care about the tld's because they take time getting them correct and I have an explosion of entries in my projects. Also, the struts tld's (at least in 1.0.2) are missing attributes. We are actively fixing the TLDs for 1.1 -- please report specific ones that you find missing in 1.1b2 as bug reports. HTML and all the other languages we use are hard enough to learn and get effective with, using consistent syntax much less inconsistent syntax. Yes there are differences and the class would be slightly larger than normal but it wouldn't be unmanageable and with clever syntactic analysis would not be much larger. After all the browser has to be built to handle the input html object. I'm not at all interested in combining all the various kinds of HTML input tags into a single Struts tag (even if we were willing to break backwards compatibility in this way). The W3C spec for input is the about the worst example of a spec definition that I've never seen, because many of the specified elements are relevant for only some of the input subtypes, and the relationships are not always clearly defined. We'd just end up with a single tag that had 100 or so optional attirbutes, with no clue to the poor user about which ones are relevant for which uses. Thanks for your commentary. Edgar Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
If the 1.0.2 tlds are missing attributes that the tags support, you should submit a bug report in bugzilla. Also, if you want to refactor the various struts tags dealing with input types into one tag I'd be very interested in seeing it. Yes, browsers have to handle one html input tag for the various kinds of inputs but they don't have to deal with java as well. Struts tags must accept valid html attributes AND attributes dealing with sources of data and other java stuff. David From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: LabelTag Date: Tue, 15 Oct 2002 13:24:56 -0400 I guess we have a difference of opinion. I care about the tld's because they take time getting them correct and I have an explosion of entries in my projects. Also, the struts tld's (at least in 1.0.2) are missing attributes. HTML and all the other languages we use are hard enough to learn and get effective with, using consistent syntax much less inconsistent syntax. Yes there are differences and the class would be slightly larger than normal but it wouldn't be unmanageable and with clever syntactic analysis would not be much larger. After all the browser has to be built to handle the input html object. Thanks for your commentary. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 12:50 PM To: [EMAIL PROTECTED] Subject: RE: LabelTag I think your suggestion on having one struts tag that emits any input type (like the html spec) is very flawed. Consider how huge that one tag would be if it knew how to output text, textarea, radio, checkbox, submit, and password fields. Each of the struts input tags have features unique to them and deserve to be separate. Also, the struts tags need attributes for html AND beans, properties, etc. That's why you see attributes like styleClass instead of class. Who cares how many tld entries there are? This is a non-issue, especially in servlet 2.3 where you don't ever have to see the tlds. Even without 2.3, it's trivial to put struts-*.tld files in your /WEB-INF directory. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LabelTag
Edgar, Just for the record, I agree with your sentiment about the Struts HTML tags. styleClass drives me nuts! But I don't have time to change it, much less deal with the backwards compatibility issues the committers would demand of such a change :) so, I just deal with it and work with whats there. And like Ted said, JSTL is where the taglib work should be done, except for Struts-specific tags, so when things are being refactored we should lobby for HTML attributes to be supported with no name changes and anything that is Struts-specific should have a different attribute name, rather than renaming an HTML attribute. But, we're off topic :) Erik Edgar Dollin wrote: I guess we have a difference of opinion. I care about the tld's because they take time getting them correct and I have an explosion of entries in my projects. Also, the struts tld's (at least in 1.0.2) are missing attributes. HTML and all the other languages we use are hard enough to learn and get effective with, using consistent syntax much less inconsistent syntax. Yes there are differences and the class would be slightly larger than normal but it wouldn't be unmanageable and with clever syntactic analysis would not be much larger. After all the browser has to be built to handle the input html object. Thanks for your commentary. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 12:50 PM To: [EMAIL PROTECTED] Subject: RE: LabelTag I think your suggestion on having one struts tag that emits any input type (like the html spec) is very flawed. Consider how huge that one tag would be if it knew how to output text, textarea, radio, checkbox, submit, and password fields. Each of the struts input tags have features unique to them and deserve to be separate. Also, the struts tags need attributes for html AND beans, properties, etc. That's why you see attributes like styleClass instead of class. Who cares how many tld entries there are? This is a non-issue, especially in servlet 2.3 where you don't ever have to see the tlds. Even without 2.3, it's trivial to put struts-*.tld files in your /WEB-INF directory. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 10:32 AM To: Struts Developers List Subject: RE: LabelTag backwards compatibility in this way). The W3C spec for input is the about the worst example of a spec definition that I've never seen, because many of the specified elements are relevant for only some of the input subtypes, and the relationships are not always clearly defined. We'd just end up with a single tag that had 100 or so optional attirbutes, with no clue to the poor user about which ones are relevant for which uses. For an example of this, consider type hidden. The HTML 4.01 spec defines several attributes of the input element which really are only relevant to elements which take visible space on the screen. The specification doesn't specify (somewhat understandably) that concrete subclasses of input shouldn't use certain attributes, so as a result the Struts implementation of the html:hidden tag implements several attributes that are only there to provide compliance to the specification, but no useful value. If the specification allocated responsibilities to these elements more rationally, the input element would have been divided into more than one real element. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I like the idea. I do see a couple of problems, however. * You are presumably defining the juxtaposition of the label, the colon, the asterisk, and the input field, in the tag itself. This, I think, would be rather specific to the layout you have in mind. * The use of a trailing colon is very much locale-dependent. In some languages (e.g. Finnish), the use of a trailing colon actually changes the meaning of the text before it. In such cases, a somewhat different layout may be desired. Certainly, neither of these is insurmountable. In fact, if they could be resolved in such a way that the tag supports full i18n and is still easy to use, this would be a very handy tag. -- Martin Cooper -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 5:52 PM To: [EMAIL PROTECTED] Subject: LabelTag I implemented something that I think is relatively slick today, so I thought I'd share the idea. First, a change was requested to suffix all our field labels with colons. We already had this structure: thbean:message key=SomeForm.someField//th tdhtml:text property=someField//td I created a LabelTag taglib that (currently, but not necessary) subclasses MessageTag. It, of course, satisfies the request to suffix with a colon such that our message resources (now in the database) are not changed, and the JSP does not have colons. But, I figured why stop there, so I dug through ValidatorResources and added in an asterisk if the field is required, and then dug through ActionErrors and turned the field red (using CSS classes and a span) if the field was in error. This is a feature I've been thinking of for a while, and I'm sure others have implemented similar features, but its such a big enhancement that I felt like sharing it! I'm not sure if this is worthy of making more generic and contributing though. Thoughts? Its dependent on your forms subclassing ValidatorForm and validation.xml be used appropriately, and it also relies on field labels adhering to the form name.field name syntax and be stored in the message resources. Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
