-----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]
Greetings,
The subject of styling form field labels based on the results of form errors
is a well-known subject on this list. And recently, and not so recently,
there have been different solutions from using struts logic tags, to
creating a Label tag that was smart about form errors. I would like to
present an alternate solution (although not really ground-breaking by any
means, and uses tools already available) that I use to accomplish the same
feature (plus some nice extras) w/o changing any Struts tags at all.
***I will follow this email up with a sample Struts application that
demonstrates this technique more clearly.***
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.
XSLT solved this problem nicely by allowing me to
1.) Style field labels/fields based on whether errors existed or not
2.) Add error messages virtually anywhere in the form (On a row on top, or
at the end of a field,etc.)
3.) Allow me to apply the same formatting and layout to all my forms
4.) Allow our page-designer(s) to affect these features w/o coding Java, or
have engineers create new tags
to support these features.
5.) Allow you to modify page elements dynamically at runtime.
Additionally page designers can create a form markup that allows them to
group the form data in a way that's more meaningful to them than relying on
what Struts might give them. The Struts tags do the heavy lifting of
getting the form data into the document, as well as create the form
elements, the template processes this document to produce the complete HTML
form with the layout (in the form of <TABLE>,etc) and formatting.
Styling based on errors comes into play when <error> elements are detected
in the document. These are placed based on the use of the Struts
<html:errors property="prop"/> tag. So if a document fragment that contains
an error is found as a sibling of a particular form field, I have a template
that styles the field like this:
<xsl:template match="fieldlabel">
<td align="center">
<!-- restart icon column -->
</td>
<td width="20%" nowrap="false">
<xsl:choose>
<xsl:when test="parent::node()/error != ''">
<span class="inline-error">
<xsl:copy-of select="."/>
</span>
</xsl:when>
<xsl:otherwise>
<span class="dialog-info"><xsl:copy-of select="."/>:</span>
</xsl:otherwise>
</xsl:choose>
</td>
</xsl:template>
This same template is applied to the Table row containing the label and
field. If this error exists, a row is inserted above that row which contains
a more descriptive error message. This of course is not a requirement as the
template enables you to place these anywhere. The form tag and it's
children are wrapped in another tag that applies this template to it's body
using a snippet similar to this:
<mytag:template name="/WEB-INF/templates/form.xml">
<html:form action="/SomeAction.do">
<fieldlabel>
<html:text property="aProp"/>
</fieldlabel>
etc...
</html:form>
</mytag:template>
***This solution does not imply that you must apply XSLT to the ENTIRE
page, just the <form> part of it***
The requirements for doing this technique are:
1.) An XSLT processor
2.) You must have a well-formed HTML form elements. Use the Struts
<html:html xhtml="true"> or <html:xhtml/> tags to enable this.
3.) You must have a DTD for any entity resolution that needs to take place.
So if you don't use a DOCTYPE you'll have to. I would strongly suggest you
use a local copy of the DTD, or create one just containing the entities you
know you'll be using. Otherwise the performance of this technique can be
killed if external resolution has to happen.
4.) An XSLT stylesheet containing the templates
5.) Wrap the <html:form> tag in the XSLT template tag.
6.) Some knowledge of XSLT, construction of basic templates, copying nodes,
etc..
I created a single tag that uses JAXP/Xalan to perform the transformation on
the body of the tag. There are also a number of XSLT tag libraries floating
around that can accomplish the same thing as the tag I wrote.
HTH,
Mike Jasnowski
-----Original Message-----
From: Mike Jasnowski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2003 9:04 AM
To: Struts Users Mailing List
Subject: RE: release candidate
If you monitor the Struts dev list you'll get a better idea about Struts
release/beta info. The last thing I saw posted was june 29th for final
-----Original Message-----
From: Zhang, Min [IT] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2003 8:37 AM
To: [EMAIL PROTECTED]
Subject: release candidate
I have been waiting for struts 1.1 release. It went through b1, b2, b3, rc1
and rc2. Any idea about the apache standred process and when the Struts 1.1
will be out? I don't see many other apache releases go this long way to a
stable release.
Thanks in advance!
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
