>That's great if all I was worrying about was the label. I also don't think >styles should necessarily be put in property files, formatting / >presentation information should be kept as it's own resource, separate from >the data it's applied to.
The enhancement is not in any way limited to labels. Every input type (checkboxs, text boxes, textareas, etc...) would benifit from the same minor code change to the BaseHandlerTag. Once this change was made, all the end-developer would have to do is set up styles/error styles in a properties file (whichever one they want). There would be zero change to how the gui developer would use the struts custom tags. I don't care (nor to i want to limit) which bundle the user wants to store the style info in. But I do feel putting it in a bundle is the way to go. Being able to give locale specific error styles will always be more helpful than locking the user into a single set of styles. >I don't have a problem with how the current Struts form tags are >implemented, but when you take a form as a whole, and mix in >formatting/layout/presentation,etc info that might be replicated from JSP to >JSP, couple with a desire to make non-engineers responsible for maintaining >them (w/o writing Java code). Using something as flexible as XSLT was a >better solution than trying accomplish the same with a set of changes to JSP >tags. A main idea behind custom tags is to encapsulate complicated java code so the gui developers dont have to worry about it. IMHO, asking gui developers to start writing XSLT is equiv to putting that straight java code back in the pages. >>As far as the text descriptions of the errors, this is already handled by >><html:errors property=""/> really well. >Yes, but I'm not changing those descriptions, I'm merely providing more >control over how you can place them relative to the field they are for, as >well as the style that is applied to the label or field associated with the >error. I think straight html is always gonna be the way to go here. I don't see the benifit to saying 'put my error message after this label' or 'put my message after this input field'. I think that is too much control and is better left to the developer to put that <html:errors> tag where they want it. Jonathan -----Original Message----- From: DeRose Jonathan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 11:02 AM To: Struts Developers List Subject: RE: Form field styling/error reporting - Alternate solution [Long] >-----Original Message----- >From: Mike Jasnowski [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 25, 2003 9:55 AM >To: Struts Users Mailing List >Subject: Form field styling/error reporting - Alternate solution [Long] >The technique centers around the use of XSLT to process what appears between >the start and end <form> tags. The project I'm working had a similar >requirement of being able to highlight field labels, also possibly highlight >the field itself, as well as place a custom error message above the row. We >also wanted to allow flexibly layout and formatting of the form elements. > An initial reaction might be to create a set of form tags that were >knowledgable about form errors and provided means to style based on form >errors. If this meets your requirements then that's all well. But if you >wanted to apply this style to fields themselves, then you might end up >adding this feature to all form element types. Additionally, the placement >of field level error messages at a location not directly after the field >while maintaining the flexibility to layout and present the other field >elements complicates this somewhat. The BaseHandlerTag currently controls what styles tags use to display themselves. Making a small modification to the prepareStyles() method will get you control over every input type there is. In addition, by creating a new LabelTag that extends BaseHandlerTag, it is covered under the changes as well. If you set up what styles/error styles to use in the resource bundle, page developers get all of the error handling functionality with no changes to the jsps they write. As far as the text descriptions of the errors, this is already handled by <html:errors property=""/> really well. Jonathan --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
