struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Jasnowski" <mjasn...@bea.com>
Subject RE: Form field styling/error reporting - Alternate solution [Long]
Date Wed, 25 Jun 2003 16:22:47 GMT
>PS:  I just thought of this -- I think that using JavaScript DOM you can
>also change the value of a node, so you could change a node from <span
>>class="dialog-info"> to <span class="inline-error"> dynamically from
>>JavaScript too.  I haven't actually done it, but I think that makes
>sense.  By implementing both a JavaScript and a server-side solution,
>clients would have the convenience of instant error notification and in
>the event that JavaScript is unavailable, the error messages can be
>generated by the server.

Yup, I just opted to go with a pure-server solution for this.

-----Original Message-----
From: Erik Price [mailto:eprice@ptc.com]
Sent: Wednesday, June 25, 2003 11:06 AM
To: Struts Users Mailing List
Subject: Re: Form field styling/error reporting - Alternate solution
[Long]


Mike, this seems like a great idea.  But wouldn't it be easier to just
have the <html:errors property="prop"/> tag output the appropriate
"<span>" type directly?  This would avoid incurring the extra overhead
of XSLT, and would work on non-XML-valid pages (not that I think very
highly of non-validating pages! :)

Also, which XSLT processor are you using, and how do you like its
performance?

Erik

PS:  I just thought of this -- I think that using JavaScript DOM you can
also change the value of a node, so you could change a node from <span
class="dialog-info"> to <span class="inline-error"> dynamically from
JavaScript too.  I haven't actually done it, but I think that makes
sense.  By implementing both a JavaScript and a server-side solution,
clients would have the convenience of instant error notification and in
the event that JavaScript is unavailable, the error messages can be
generated by the server.




Mike Jasnowski wrote:
> 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:mjasnows@bea.com]
> 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:min.zhang@citigroup.com]
> Sent: Wednesday, June 25, 2003 8:37 AM
> To: struts-user@jakarta.apache.org
> 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: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>


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



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


Mime
View raw message