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: > > <th><bean:message key="SomeForm.someField"/></th> > <td><html: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]>
