You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Zhang, Min [IT]" <mi...@citigroup.com> on 2003/06/25 14:37:19 UTC
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
RE: Form field styling/error reporting - Alternate solution [Long]
Posted by Mike Jasnowski <mj...@bea.com>.
Xalan/Xerces for XSLT/XML rather
-----Original Message-----
From: Mike Jasnowski [mailto:mjasnows@bea.com]
Sent: Wednesday, June 25, 2003 12:26 PM
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! :)
True, but then this would apply to only the errors, In my case I needed to
apply it to more than just the errors, like lables and fields. I'm also of
the camp that the formatting should be external, the <html:error> should
just generate the data representing the error.
I am happy with the performance I've seen so far (sub-second), but making
the DTD local
was an absolute must to achieve this speed. The size of the documents in my
case are small-medium (since they
are just HTML forms). The rest of the HTML generated by the JSP is not
processed with this mechanism.
I'm using Xalan for the XSLT/XML parsing.
-----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
RE: Form field styling/error reporting - Alternate solution [Long]
Posted by Mike Jasnowski <mj...@bea.com>.
>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! :)
True, but then this would apply to only the errors, In my case I needed to
apply it to more than just the errors, like lables and fields. I'm also of
the camp that the formatting should be external, the <html:error> should
just generate the data representing the error.
I am happy with the performance I've seen so far (sub-second), but making
the DTD local
was an absolute must to achieve this speed. The size of the documents in my
case are small-medium (since they
are just HTML forms). The rest of the HTML generated by the JSP is not
processed with this mechanism.
I'm using Xalan for the XSLT/XML parsing.
-----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
RE: Form field styling/error reporting - Alternate solution [Long]
Posted by Mike Jasnowski <mj...@bea.com>.
>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
Re: Form field styling/error reporting - Alternate solution [Long]
Posted by Erik Price <ep...@ptc.com>.
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
Form field styling/error reporting - Alternate solution [Long]
Posted by Mike Jasnowski <mj...@bea.com>.
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
RE: release candidate
Posted by Mike Jasnowski <mj...@bea.com>.
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