You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Martin Cooper <ma...@tumbleweed.com> on 2000/09/21 06:27:47 UTC
An enhancement for ?
Right now, if there are multiple error messages to be output by the
<struts:errors> tag, they will be separated by newlines. This means they
effectively run together when displayed in an HTML page. Unless I'm missing
something, any formatting has to be included within the messages themselves.
What about extending ErrorsTag to use an errors.format value as well as
errors.header and errors.footer, where this string would be used with
MessageFormat? This would allow much more control over the presentation. For
example, with the following values:
errors.header="<table>"
errors.format="<tr><td>{0}</td></tr>"
errors.footer="</table>"
the errors would be displayed as a table, one row per error message.
--
Martin Cooper
Tumbleweed Communications
Re[4]: An enhancement for ?
Posted by Oleg V Alexeev <go...@penza.net>.
Yes. Support for parameters in error messages can be great enhansment
for error processing.
ErrorMessages error = new ErrorMessages();
Vector parset = new Vector();
parset.add( new Integer( leftValue ) ); //left border of range
parset.add( new Integer( rightValue ) ); //right border of range
parset.add( new Float( sampleValue ) ); //sample value
parset.add( "some.form" ); //source
errors.add( "errors.out.of.range", parset );
PM> I advocated for such a mechanism two months ago. Dont't forget to allow
PM> parameters substitution in the message text...
PM> In code:
PM> ErrorMessages errors = new ErrorMessages();
PM> errors.addError( "form.percentIncrease", "outOfRange", "1", "99" );
PM> Would print "percentage must be in the range [1, 99]" or "le pourcentage
PM> doit se situer dans l'intervalle [1, 99]"...
PM> Pierre Métras
PM> ----- Original Message -----
PM> From: "Joe Walnes" <jo...@wirestation.co.uk>
PM> To: <st...@jakarta.apache.org>; "Oleg V Alexeev" <go...@penza.net>
PM> Sent: Thursday, September 21, 2000 12:24 PM
PM> Subject: RE: Re[2]: An enhancement for <struts:errors>?
>> Yes. That would also allow you to place error msgs in relevent places too
>> (ie: next to the field they are associate with), thereby creating a much
>> more intuitive interface for the end user.
>>
>> -Joe Walnes
>>
>>
>>
>> -----Original Message-----
>> From: Oleg V Alexeev [mailto:gonza@penza.net]
>> Sent: 21 September 2000 17:13
>> To: Joe Walnes
>> Subject: Re[2]: An enhancement for <struts:errors>?
>>
>>
>> Error processing can be more flexible when error message would be
>> broken to part of error 'source' and part of error 'message'.
>>
>> In code:
>>
>> ErrorMessages errors = new ErrorMessages();
>>
>> errors.addError( "form.fieldname1", "not.filled" );
>> errors.addError( "form.fieldname2", "not.filled" );
>> ^ ^
>> source message
>>
>> In resources:
>>
>> form.fieldname1=Name of anything
>> form.fieldname2=Description of anything
>> not.filled=Fill this field, please
>>
>> In *.jsp
>>
>> <logic:present name="errors">
>> <b><struts:message key="errorHeader" /></b><br>
>> <table>
>> <logic:iterate id="currentError" name="errors">
>> <tr>
>> <td><bean:write name="currentError" property="source" /></td>
>> <td><bean:write name="currentError" property="message" /></td>
>> </tr>
>> </logic:iterate>
>> </table>
>> </logic:present>
>>
>> JW> This makes a lot more sense. There would also have to be a conditional
>> block
>> JW> as well, so error headers/footers would only be displayed if there are
>> JW> actually errors.
>>
>> JW> ie:
>>
>> JW> <struts:errorsPresent>
>> JW> <b><struts:message key="errorHeader" /></b>
>> JW> <ul>
>> JW> <struts:listErrors>
>> JW> <li><struts:errorMsg /></li>
>> JW> </struts:listErrors>
>> JW> </ul>
>> JW> </struts:errorsPresent>
>>
>> JW> Hmm... all those tags look familiar. <struts:errorPresent> looks like
>> JW> <logic:present>, <struts:listErrors> looks like <logic:iterate> and
>> JW> <struts:errorMsg> looks like <struts:message>.
>>
>> JW> If the errors were exposed to page as a bean, and the <struts:message>
>> tag
>> JW> could accept dynamic keys, very flexible error messages could be
>> generated
>> JW> like:
>>
>> JW> <logic:present name="errors">
>> JW> <b><struts:message key="errorHeader" /></b>
>> JW> <ul>
>> JW> <logic:iterate id="currentError" name="errors">
>> JW> <li><struts:message name="currentError"
/>></li>
>> JW> </logic:iterate>
>> JW> </ul>
>> JW> </logic:present>
>>
>> JW> Is an error tag needed at all? For convenience it's very useful, but
PM> the
>> JW> other tags provide a much more flexible means for displaying errors.
>>
>> JW> -Joe Walnes
>>
>>
>> JW> -----Original Message-----
>> JW> From: Chris Miller [mailto:kiwi@vardus.com]
>> JW> Sent: 21 September 2000 07:53
>> JW> To: struts-user@jakarta.apache.org
>> JW> Subject: Re: An enhancement for <struts:errors>?
>>
>>
>> JW> Even better than that would be to write a <struts:listErrors> tag that
>> would
>> JW> iterate over the errors.
>> JW> That way any arbitrary formatting could be applied, on a case-by-case
>> basis
>> JW> if so desired. Also, it would be nice to remove the HTML from the
>> properties
>> JW> file - I really don't think it belongs in there.
>>
>> JW> eg.
>>
>> JW> <struts:listErrors error="error" count="count">
>> JW> <font color="red"><%= error %></font><br>
>> JW> </struts:listErrrors>
>> JW> <% if (count > 0) { %>
>> JW> <p/>Please correct the above problems before continuing
>> JW> <% } %>
>>
>> JW> The above code would problably be put in a separate file and included
>> using
>> JW> <struts:include>.
>>
>> JW> What do you think?
>>
>>
>> JW> ----- Original Message -----
>> JW> From: "Martin Cooper" <ma...@tumbleweed.com>
>> JW> To: <st...@jakarta.apache.org>
>> JW> Sent: Thursday, September 21, 2000 5:27 AM
>> JW> Subject: An enhancement for <struts:errors>?
>>
>>
>> >> Right now, if there are multiple error messages to be output by the
>> >> <struts:errors> tag, they will be separated by newlines. This means
PM> they
>> >> effectively run together when displayed in an HTML page. Unless I'm
>> JW> missing
>> >> something, any formatting has to be included within the messages
>> JW> themselves.
>> >>
>> >> What about extending ErrorsTag to use an errors.format value as well as
>> >> errors.header and errors.footer, where this string would be used with
>> >> MessageFormat? This would allow much more control over the
PM> presentation.
>> JW> For
>> >> example, with the following values:
>> >>
>> >> errors.header="<table>"
>> >> errors.format="<tr><td>{0}</td></tr>"
>> >> errors.footer="</table>"
>> >>
>> >> the errors would be displayed as a table, one row per error message.
>> >>
>> >> --
>> >> Martin Cooper
>> >> Tumbleweed Communications
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>> --
>> Best regards,
>> Oleg mailto:gonza@penza.net
>>
>>
>>
--
Best regards,
Oleg mailto:gonza@penza.net
Re: struts-example now broken?
Posted by Don Jones <do...@kdsi.net>.
Craig -
We would also appreciate the 'Milestone 0' release and fix path if you can do
this. We will be completing our prototype stage and bring in several teams for
our development beginning in the next 1-2 weeks. We will use the latest release
we can get working at that point and it would be great to be able to have a
relatively stable path to follow until 1.0 is ready.
Cheers,
Don Jones
Chief Architect
Dove Solutions
"Craig R. McClanahan" wrote:
> Joel Schneider wrote:
>
> > The project I'm working on is in the process of picking a daily build of
> > struts upon which, for the time being, we will base our development
> > efforts. It would be nice to use the most recent possible build, but
> > I'm a little concerned about a problem that has cropped up in the 20000920
> > and later builds.
> >
> > Using the 20000919 build, I've seen no problem running the
> > struts-documentation, struts-example, and struts-test applications.
> > However, although the 20000920 and 20000921 builds are able to serve
> > struts-documentation and struts-test, (under an identical Orion
> > configuration) they produce an error message when attempting to display
> > pages from struts-example:
> >
> > 500 Internal Server Error
> >
> > javax.servlet.jsp.JspException: Missing resources attribute
> > org.apache.struts.action.MESSAGE
> > at
> > org.apache.struts.taglib.MessageTag.doStartTag(MessageTag.java:360)
> > at /index.jsp._jspService(/index.jsp.java:42) (JSP page line 6)
> > at com.evermind.server.http.EvermindHttpJspPage.service(JAX)
> > at com.evermind.server.http.HttpApplication.wa(JAX)
> > at com.evermind.server.http.JSPServlet.service(JAX)
> > at com.evermind.server.http.du.rr(JAX)
> > at com.evermind.server.http.du.forward(JAX)
> > at com.evermind.server.http.d5.rx(JAX)
> > at com.evermind.server.http.d5.rw(JAX)
> > at com.evermind.util.f.run(JAX)
> >
> > It seems that, since 20000919, a significant amount of new development
> > activity has begun. Advice on whether it might be better to start a
> > (3-month) project using 20000921 or stick with 20000919 until the
> > "dust settles" would be appreciated. We hope to move to version 1.0
> > when it becomes available...
> >
>
> I think that might be a good idea ... there is going to be a lot more
> "construction work" going on in prep for 1.0. I strive to keep backwards
> compatibility whenever possible, but some things are (unfortunately)
> guaranteed to be different in 1.0.
>
> However, for people that are using the versions of struts prior to 20000919,
> it would be feasible to post a "Milestone 0" release, and do bug fixes against
> it as a separate code path, without making you have to keep up with the
> current changes.
>
> Would that be of interest to people?
>
> >
> > Joel
>
> Craig
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
Re: struts-example now broken?
Posted by Joel Schneider <js...@cariboulake.com>.
On Thu, 21 Sep 2000, Craig R. McClanahan wrote:
>
> However, for people that are using the versions of struts prior to 20000919,
> it would be feasible to post a "Milestone 0" release, and do bug fixes against
> it as a separate code path, without making you have to keep up with the
> current changes.
>
> Would that be of interest to people?
That would be great!
Joel
Re: struts-example now broken?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Joel Schneider wrote:
> The project I'm working on is in the process of picking a daily build of
> struts upon which, for the time being, we will base our development
> efforts. It would be nice to use the most recent possible build, but
> I'm a little concerned about a problem that has cropped up in the 20000920
> and later builds.
>
> Using the 20000919 build, I've seen no problem running the
> struts-documentation, struts-example, and struts-test applications.
> However, although the 20000920 and 20000921 builds are able to serve
> struts-documentation and struts-test, (under an identical Orion
> configuration) they produce an error message when attempting to display
> pages from struts-example:
>
> 500 Internal Server Error
>
> javax.servlet.jsp.JspException: Missing resources attribute
> org.apache.struts.action.MESSAGE
> at
> org.apache.struts.taglib.MessageTag.doStartTag(MessageTag.java:360)
> at /index.jsp._jspService(/index.jsp.java:42) (JSP page line 6)
> at com.evermind.server.http.EvermindHttpJspPage.service(JAX)
> at com.evermind.server.http.HttpApplication.wa(JAX)
> at com.evermind.server.http.JSPServlet.service(JAX)
> at com.evermind.server.http.du.rr(JAX)
> at com.evermind.server.http.du.forward(JAX)
> at com.evermind.server.http.d5.rx(JAX)
> at com.evermind.server.http.d5.rw(JAX)
> at com.evermind.util.f.run(JAX)
>
> It seems that, since 20000919, a significant amount of new development
> activity has begun. Advice on whether it might be better to start a
> (3-month) project using 20000921 or stick with 20000919 until the
> "dust settles" would be appreciated. We hope to move to version 1.0
> when it becomes available...
>
I think that might be a good idea ... there is going to be a lot more
"construction work" going on in prep for 1.0. I strive to keep backwards
compatibility whenever possible, but some things are (unfortunately)
guaranteed to be different in 1.0.
However, for people that are using the versions of struts prior to 20000919,
it would be feasible to post a "Milestone 0" release, and do bug fixes against
it as a separate code path, without making you have to keep up with the
current changes.
Would that be of interest to people?
>
> Joel
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
struts-example now broken?
Posted by Joel Schneider <js...@cariboulake.com>.
The project I'm working on is in the process of picking a daily build of
struts upon which, for the time being, we will base our development
efforts. It would be nice to use the most recent possible build, but
I'm a little concerned about a problem that has cropped up in the 20000920
and later builds.
Using the 20000919 build, I've seen no problem running the
struts-documentation, struts-example, and struts-test applications.
However, although the 20000920 and 20000921 builds are able to serve
struts-documentation and struts-test, (under an identical Orion
configuration) they produce an error message when attempting to display
pages from struts-example:
500 Internal Server Error
javax.servlet.jsp.JspException: Missing resources attribute
org.apache.struts.action.MESSAGE
at
org.apache.struts.taglib.MessageTag.doStartTag(MessageTag.java:360)
at /index.jsp._jspService(/index.jsp.java:42) (JSP page line 6)
at com.evermind.server.http.EvermindHttpJspPage.service(JAX)
at com.evermind.server.http.HttpApplication.wa(JAX)
at com.evermind.server.http.JSPServlet.service(JAX)
at com.evermind.server.http.du.rr(JAX)
at com.evermind.server.http.du.forward(JAX)
at com.evermind.server.http.d5.rx(JAX)
at com.evermind.server.http.d5.rw(JAX)
at com.evermind.util.f.run(JAX)
It seems that, since 20000919, a significant amount of new development
activity has begun. Advice on whether it might be better to start a
(3-month) project using 20000921 or stick with 20000919 until the
"dust settles" would be appreciated. We hope to move to version 1.0
when it becomes available...
Joel
Re: Re[2]: An enhancement for ?
Posted by Pierre Métras <ge...@sympatico.ca>.
I advocated for such a mechanism two months ago. Dont't forget to allow
parameters substitution in the message text...
In code:
ErrorMessages errors = new ErrorMessages();
errors.addError( "form.percentIncrease", "outOfRange", "1", "99" );
Would print "percentage must be in the range [1, 99]" or "le pourcentage
doit se situer dans l'intervalle [1, 99]"...
Pierre Métras
----- Original Message -----
From: "Joe Walnes" <jo...@wirestation.co.uk>
To: <st...@jakarta.apache.org>; "Oleg V Alexeev" <go...@penza.net>
Sent: Thursday, September 21, 2000 12:24 PM
Subject: RE: Re[2]: An enhancement for <struts:errors>?
> Yes. That would also allow you to place error msgs in relevent places too
> (ie: next to the field they are associate with), thereby creating a much
> more intuitive interface for the end user.
>
> -Joe Walnes
>
>
>
> -----Original Message-----
> From: Oleg V Alexeev [mailto:gonza@penza.net]
> Sent: 21 September 2000 17:13
> To: Joe Walnes
> Subject: Re[2]: An enhancement for <struts:errors>?
>
>
> Error processing can be more flexible when error message would be
> broken to part of error 'source' and part of error 'message'.
>
> In code:
>
> ErrorMessages errors = new ErrorMessages();
>
> errors.addError( "form.fieldname1", "not.filled" );
> errors.addError( "form.fieldname2", "not.filled" );
> ^ ^
> source message
>
> In resources:
>
> form.fieldname1=Name of anything
> form.fieldname2=Description of anything
> not.filled=Fill this field, please
>
> In *.jsp
>
> <logic:present name="errors">
> <b><struts:message key="errorHeader" /></b><br>
> <table>
> <logic:iterate id="currentError" name="errors">
> <tr>
> <td><bean:write name="currentError" property="source" /></td>
> <td><bean:write name="currentError" property="message" /></td>
> </tr>
> </logic:iterate>
> </table>
> </logic:present>
>
> JW> This makes a lot more sense. There would also have to be a conditional
> block
> JW> as well, so error headers/footers would only be displayed if there are
> JW> actually errors.
>
> JW> ie:
>
> JW> <struts:errorsPresent>
> JW> <b><struts:message key="errorHeader" /></b>
> JW> <ul>
> JW> <struts:listErrors>
> JW> <li><struts:errorMsg /></li>
> JW> </struts:listErrors>
> JW> </ul>
> JW> </struts:errorsPresent>
>
> JW> Hmm... all those tags look familiar. <struts:errorPresent> looks like
> JW> <logic:present>, <struts:listErrors> looks like <logic:iterate> and
> JW> <struts:errorMsg> looks like <struts:message>.
>
> JW> If the errors were exposed to page as a bean, and the <struts:message>
> tag
> JW> could accept dynamic keys, very flexible error messages could be
> generated
> JW> like:
>
> JW> <logic:present name="errors">
> JW> <b><struts:message key="errorHeader" /></b>
> JW> <ul>
> JW> <logic:iterate id="currentError" name="errors">
> JW> <li><struts:message name="currentError"
/></li>
> JW> </logic:iterate>
> JW> </ul>
> JW> </logic:present>
>
> JW> Is an error tag needed at all? For convenience it's very useful, but
the
> JW> other tags provide a much more flexible means for displaying errors.
>
> JW> -Joe Walnes
>
>
> JW> -----Original Message-----
> JW> From: Chris Miller [mailto:kiwi@vardus.com]
> JW> Sent: 21 September 2000 07:53
> JW> To: struts-user@jakarta.apache.org
> JW> Subject: Re: An enhancement for <struts:errors>?
>
>
> JW> Even better than that would be to write a <struts:listErrors> tag that
> would
> JW> iterate over the errors.
> JW> That way any arbitrary formatting could be applied, on a case-by-case
> basis
> JW> if so desired. Also, it would be nice to remove the HTML from the
> properties
> JW> file - I really don't think it belongs in there.
>
> JW> eg.
>
> JW> <struts:listErrors error="error" count="count">
> JW> <font color="red"><%= error %></font><br>
> JW> </struts:listErrrors>
> JW> <% if (count > 0) { %>
> JW> <p/>Please correct the above problems before continuing
> JW> <% } %>
>
> JW> The above code would problably be put in a separate file and included
> using
> JW> <struts:include>.
>
> JW> What do you think?
>
>
> JW> ----- Original Message -----
> JW> From: "Martin Cooper" <ma...@tumbleweed.com>
> JW> To: <st...@jakarta.apache.org>
> JW> Sent: Thursday, September 21, 2000 5:27 AM
> JW> Subject: An enhancement for <struts:errors>?
>
>
> >> Right now, if there are multiple error messages to be output by the
> >> <struts:errors> tag, they will be separated by newlines. This means
they
> >> effectively run together when displayed in an HTML page. Unless I'm
> JW> missing
> >> something, any formatting has to be included within the messages
> JW> themselves.
> >>
> >> What about extending ErrorsTag to use an errors.format value as well as
> >> errors.header and errors.footer, where this string would be used with
> >> MessageFormat? This would allow much more control over the
presentation.
> JW> For
> >> example, with the following values:
> >>
> >> errors.header="<table>"
> >> errors.format="<tr><td>{0}</td></tr>"
> >> errors.footer="</table>"
> >>
> >> the errors would be displayed as a table, one row per error message.
> >>
> >> --
> >> Martin Cooper
> >> Tumbleweed Communications
> >>
> >>
> >>
> >>
>
>
>
> --
> Best regards,
> Oleg mailto:gonza@penza.net
>
>
>
Re: An enhancement for ?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Rod McChesney wrote:
> > Yes. That would also allow you to place error msgs in relevent places > too
>
> That's a key feature, IMHO. A list of error messages up top is not
> nearly as useful as having them next to the place where they appeared.
> Usually you want an overall message at the top saying there was a
> problem somewhere, in case the part of the form with the error
> is scrolled off the bottom. Someone suggested a way of focusing on
> the first problematic field, too, which is also a nice feature.
>
> Rod McChesney
>
I can definitely see the merit of these ideas. And, they let us eat our own dog
food (err, re-use tags we've already written :-).
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: An enhancement for ?
Posted by Rod McChesney <ro...@expressaction.com>.
> Yes. That would also allow you to place error msgs in relevent places > too
That's a key feature, IMHO. A list of error messages up top is not
nearly as useful as having them next to the place where they appeared.
Usually you want an overall message at the top saying there was a
problem somewhere, in case the part of the form with the error
is scrolled off the bottom. Someone suggested a way of focusing on
the first problematic field, too, which is also a nice feature.
Rod McChesney
Joe Walnes wrote:
>
> Yes. That would also allow you to place error msgs in relevent places too
> (ie: next to the field they are associate with), thereby creating a much
> more intuitive interface for the end user.
>
> -Joe Walnes
>
> -----Original Message-----
> From: Oleg V Alexeev [mailto:gonza@penza.net]
> Sent: 21 September 2000 17:13
> To: Joe Walnes
> Subject: Re[2]: An enhancement for <struts:errors>?
>
> Error processing can be more flexible when error message would be
> broken to part of error 'source' and part of error 'message'.
>
> In code:
>
> ErrorMessages errors = new ErrorMessages();
>
> errors.addError( "form.fieldname1", "not.filled" );
> errors.addError( "form.fieldname2", "not.filled" );
> ^ ^
> source message
>
> In resources:
>
> form.fieldname1=Name of anything
> form.fieldname2=Description of anything
> not.filled=Fill this field, please
>
> In *.jsp
>
> <logic:present name="errors">
> <b><struts:message key="errorHeader" /></b><br>
> <table>
> <logic:iterate id="currentError" name="errors">
> <tr>
> <td><bean:write name="currentError" property="source" /></td>
> <td><bean:write name="currentError" property="message" /></td>
> </tr>
> </logic:iterate>
> </table>
> </logic:present>
>
> JW> This makes a lot more sense. There would also have to be a conditional
> block
> JW> as well, so error headers/footers would only be displayed if there are
> JW> actually errors.
>
> JW> ie:
>
> JW> <struts:errorsPresent>
> JW> <b><struts:message key="errorHeader" /></b>
> JW> <ul>
> JW> <struts:listErrors>
> JW> <li><struts:errorMsg /></li>
> JW> </struts:listErrors>
> JW> </ul>
> JW> </struts:errorsPresent>
>
> JW> Hmm... all those tags look familiar. <struts:errorPresent> looks like
> JW> <logic:present>, <struts:listErrors> looks like <logic:iterate> and
> JW> <struts:errorMsg> looks like <struts:message>.
>
> JW> If the errors were exposed to page as a bean, and the <struts:message>
> tag
> JW> could accept dynamic keys, very flexible error messages could be
> generated
> JW> like:
>
> JW> <logic:present name="errors">
> JW> <b><struts:message key="errorHeader" /></b>
> JW> <ul>
> JW> <logic:iterate id="currentError" name="errors">
> JW> <li><struts:message name="currentError" /></li>
> JW> </logic:iterate>
> JW> </ul>
> JW> </logic:present>
>
> JW> Is an error tag needed at all? For convenience it's very useful, but the
> JW> other tags provide a much more flexible means for displaying errors.
>
> JW> -Joe Walnes
>
> JW> -----Original Message-----
> JW> From: Chris Miller [mailto:kiwi@vardus.com]
> JW> Sent: 21 September 2000 07:53
> JW> To: struts-user@jakarta.apache.org
> JW> Subject: Re: An enhancement for <struts:errors>?
>
> JW> Even better than that would be to write a <struts:listErrors> tag that
> would
> JW> iterate over the errors.
> JW> That way any arbitrary formatting could be applied, on a case-by-case
> basis
> JW> if so desired. Also, it would be nice to remove the HTML from the
> properties
> JW> file - I really don't think it belongs in there.
>
> JW> eg.
>
> JW> <struts:listErrors error="error" count="count">
> JW> <font color="red"><%= error %></font><br>
> JW> </struts:listErrrors>
> JW> <% if (count > 0) { %>
> JW> <p/>Please correct the above problems before continuing
> JW> <% } %>
>
> JW> The above code would problably be put in a separate file and included
> using
> JW> <struts:include>.
>
> JW> What do you think?
>
> JW> ----- Original Message -----
> JW> From: "Martin Cooper" <ma...@tumbleweed.com>
> JW> To: <st...@jakarta.apache.org>
> JW> Sent: Thursday, September 21, 2000 5:27 AM
> JW> Subject: An enhancement for <struts:errors>?
>
> >> Right now, if there are multiple error messages to be output by the
> >> <struts:errors> tag, they will be separated by newlines. This means they
> >> effectively run together when displayed in an HTML page. Unless I'm
> JW> missing
> >> something, any formatting has to be included within the messages
> JW> themselves.
> >>
> >> What about extending ErrorsTag to use an errors.format value as well as
> >> errors.header and errors.footer, where this string would be used with
> >> MessageFormat? This would allow much more control over the presentation.
> JW> For
> >> example, with the following values:
> >>
> >> errors.header="<table>"
> >> errors.format="<tr><td>{0}</td></tr>"
> >> errors.footer="</table>"
> >>
> >> the errors would be displayed as a table, one row per error message.
> >>
> >> --
> >> Martin Cooper
> >> Tumbleweed Communications
RE: Re[2]: An enhancement for ?
Posted by Joe Walnes <jo...@wirestation.co.uk>.
Yes. That would also allow you to place error msgs in relevent places too
(ie: next to the field they are associate with), thereby creating a much
more intuitive interface for the end user.
-Joe Walnes
-----Original Message-----
From: Oleg V Alexeev [mailto:gonza@penza.net]
Sent: 21 September 2000 17:13
To: Joe Walnes
Subject: Re[2]: An enhancement for <struts:errors>?
Error processing can be more flexible when error message would be
broken to part of error 'source' and part of error 'message'.
In code:
ErrorMessages errors = new ErrorMessages();
errors.addError( "form.fieldname1", "not.filled" );
errors.addError( "form.fieldname2", "not.filled" );
^ ^
source message
In resources:
form.fieldname1=Name of anything
form.fieldname2=Description of anything
not.filled=Fill this field, please
In *.jsp
<logic:present name="errors">
<b><struts:message key="errorHeader" /></b><br>
<table>
<logic:iterate id="currentError" name="errors">
<tr>
<td><bean:write name="currentError" property="source" /></td>
<td><bean:write name="currentError" property="message" /></td>
</tr>
</logic:iterate>
</table>
</logic:present>
JW> This makes a lot more sense. There would also have to be a conditional
block
JW> as well, so error headers/footers would only be displayed if there are
JW> actually errors.
JW> ie:
JW> <struts:errorsPresent>
JW> <b><struts:message key="errorHeader" /></b>
JW> <ul>
JW> <struts:listErrors>
JW> <li><struts:errorMsg /></li>
JW> </struts:listErrors>
JW> </ul>
JW> </struts:errorsPresent>
JW> Hmm... all those tags look familiar. <struts:errorPresent> looks like
JW> <logic:present>, <struts:listErrors> looks like <logic:iterate> and
JW> <struts:errorMsg> looks like <struts:message>.
JW> If the errors were exposed to page as a bean, and the <struts:message>
tag
JW> could accept dynamic keys, very flexible error messages could be
generated
JW> like:
JW> <logic:present name="errors">
JW> <b><struts:message key="errorHeader" /></b>
JW> <ul>
JW> <logic:iterate id="currentError" name="errors">
JW> <li><struts:message name="currentError" /></li>
JW> </logic:iterate>
JW> </ul>
JW> </logic:present>
JW> Is an error tag needed at all? For convenience it's very useful, but the
JW> other tags provide a much more flexible means for displaying errors.
JW> -Joe Walnes
JW> -----Original Message-----
JW> From: Chris Miller [mailto:kiwi@vardus.com]
JW> Sent: 21 September 2000 07:53
JW> To: struts-user@jakarta.apache.org
JW> Subject: Re: An enhancement for <struts:errors>?
JW> Even better than that would be to write a <struts:listErrors> tag that
would
JW> iterate over the errors.
JW> That way any arbitrary formatting could be applied, on a case-by-case
basis
JW> if so desired. Also, it would be nice to remove the HTML from the
properties
JW> file - I really don't think it belongs in there.
JW> eg.
JW> <struts:listErrors error="error" count="count">
JW> <font color="red"><%= error %></font><br>
JW> </struts:listErrrors>
JW> <% if (count > 0) { %>
JW> <p/>Please correct the above problems before continuing
JW> <% } %>
JW> The above code would problably be put in a separate file and included
using
JW> <struts:include>.
JW> What do you think?
JW> ----- Original Message -----
JW> From: "Martin Cooper" <ma...@tumbleweed.com>
JW> To: <st...@jakarta.apache.org>
JW> Sent: Thursday, September 21, 2000 5:27 AM
JW> Subject: An enhancement for <struts:errors>?
>> Right now, if there are multiple error messages to be output by the
>> <struts:errors> tag, they will be separated by newlines. This means they
>> effectively run together when displayed in an HTML page. Unless I'm
JW> missing
>> something, any formatting has to be included within the messages
JW> themselves.
>>
>> What about extending ErrorsTag to use an errors.format value as well as
>> errors.header and errors.footer, where this string would be used with
>> MessageFormat? This would allow much more control over the presentation.
JW> For
>> example, with the following values:
>>
>> errors.header="<table>"
>> errors.format="<tr><td>{0}</td></tr>"
>> errors.footer="</table>"
>>
>> the errors would be displayed as a table, one row per error message.
>>
>> --
>> Martin Cooper
>> Tumbleweed Communications
>>
>>
>>
>>
--
Best regards,
Oleg mailto:gonza@penza.net
Re[2]: An enhancement for ?
Posted by Oleg V Alexeev <go...@penza.net>.
Error processing can be more flexible when error message would be
broken to part of error 'source' and part of error 'message'.
In code:
ErrorMessages errors = new ErrorMessages();
errors.addError( "form.fieldname1", "not.filled" );
errors.addError( "form.fieldname2", "not.filled" );
^ ^
source message
In resources:
form.fieldname1=Name of anything
form.fieldname2=Description of anything
not.filled=Fill this field, please
In *.jsp
<logic:present name="errors">
<b><struts:message key="errorHeader" /></b><br>
<table>
<logic:iterate id="currentError" name="errors">
<tr>
<td><bean:write name="currentError" property="source" /></td>
<td><bean:write name="currentError" property="message" /></td>
</tr>
</logic:iterate>
</table>
</logic:present>
JW> This makes a lot more sense. There would also have to be a conditional block
JW> as well, so error headers/footers would only be displayed if there are
JW> actually errors.
JW> ie:
JW> <struts:errorsPresent>
JW> <b><struts:message key="errorHeader" /></b>
JW> <ul>
JW> <struts:listErrors>
JW> <li><struts:errorMsg /></li>
JW> </struts:listErrors>
JW> </ul>
JW> </struts:errorsPresent>
JW> Hmm... all those tags look familiar. <struts:errorPresent> looks like
JW> <logic:present>, <struts:listErrors> looks like <logic:iterate> and
JW> <struts:errorMsg> looks like <struts:message>.
JW> If the errors were exposed to page as a bean, and the <struts:message> tag
JW> could accept dynamic keys, very flexible error messages could be generated
JW> like:
JW> <logic:present name="errors">
JW> <b><struts:message key="errorHeader" /></b>
JW> <ul>
JW> <logic:iterate id="currentError" name="errors">
JW> <li><struts:message name="currentError" /></li>
JW> </logic:iterate>
JW> </ul>
JW> </logic:present>
JW> Is an error tag needed at all? For convenience it's very useful, but the
JW> other tags provide a much more flexible means for displaying errors.
JW> -Joe Walnes
JW> -----Original Message-----
JW> From: Chris Miller [mailto:kiwi@vardus.com]
JW> Sent: 21 September 2000 07:53
JW> To: struts-user@jakarta.apache.org
JW> Subject: Re: An enhancement for <struts:errors>?
JW> Even better than that would be to write a <struts:listErrors> tag that would
JW> iterate over the errors.
JW> That way any arbitrary formatting could be applied, on a case-by-case basis
JW> if so desired. Also, it would be nice to remove the HTML from the properties
JW> file - I really don't think it belongs in there.
JW> eg.
JW> <struts:listErrors error="error" count="count">
JW> <font color="red"><%= error %></font><br>
JW> </struts:listErrrors>
JW> <% if (count > 0) { %>
JW> <p/>Please correct the above problems before continuing
JW> <% } %>
JW> The above code would problably be put in a separate file and included using
JW> <struts:include>.
JW> What do you think?
JW> ----- Original Message -----
JW> From: "Martin Cooper" <ma...@tumbleweed.com>
JW> To: <st...@jakarta.apache.org>
JW> Sent: Thursday, September 21, 2000 5:27 AM
JW> Subject: An enhancement for <struts:errors>?
>> Right now, if there are multiple error messages to be output by the
>> <struts:errors> tag, they will be separated by newlines. This means they
>> effectively run together when displayed in an HTML page. Unless I'm
JW> missing
>> something, any formatting has to be included within the messages
JW> themselves.
>>
>> What about extending ErrorsTag to use an errors.format value as well as
>> errors.header and errors.footer, where this string would be used with
>> MessageFormat? This would allow much more control over the presentation.
JW> For
>> example, with the following values:
>>
>> errors.header="<table>"
>> errors.format="<tr><td>{0}</td></tr>"
>> errors.footer="</table>"
>>
>> the errors would be displayed as a table, one row per error message.
>>
>> --
>> Martin Cooper
>> Tumbleweed Communications
>>
>>
>>
>>
--
Best regards,
Oleg mailto:gonza@penza.net
RE: An enhancement for ?
Posted by Joe Walnes <jo...@wirestation.co.uk>.
This makes a lot more sense. There would also have to be a conditional block
as well, so error headers/footers would only be displayed if there are
actually errors.
ie:
<struts:errorsPresent>
<b><struts:message key="errorHeader" /></b>
<ul>
<struts:listErrors>
<li><struts:errorMsg /></li>
</struts:listErrors>
</ul>
</struts:errorsPresent>
Hmm... all those tags look familiar. <struts:errorPresent> looks like
<logic:present>, <struts:listErrors> looks like <logic:iterate> and
<struts:errorMsg> looks like <struts:message>.
If the errors were exposed to page as a bean, and the <struts:message> tag
could accept dynamic keys, very flexible error messages could be generated
like:
<logic:present name="errors">
<b><struts:message key="errorHeader" /></b>
<ul>
<logic:iterate id="currentError" name="errors">
<li><struts:message name="currentError" /></li>
</logic:iterate>
</ul>
</logic:present>
Is an error tag needed at all? For convenience it's very useful, but the
other tags provide a much more flexible means for displaying errors.
-Joe Walnes
-----Original Message-----
From: Chris Miller [mailto:kiwi@vardus.com]
Sent: 21 September 2000 07:53
To: struts-user@jakarta.apache.org
Subject: Re: An enhancement for <struts:errors>?
Even better than that would be to write a <struts:listErrors> tag that would
iterate over the errors.
That way any arbitrary formatting could be applied, on a case-by-case basis
if so desired. Also, it would be nice to remove the HTML from the properties
file - I really don't think it belongs in there.
eg.
<struts:listErrors error="error" count="count">
<font color="red"><%= error %></font><br>
</struts:listErrrors>
<% if (count > 0) { %>
<p/>Please correct the above problems before continuing
<% } %>
The above code would problably be put in a separate file and included using
<struts:include>.
What do you think?
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, September 21, 2000 5:27 AM
Subject: An enhancement for <struts:errors>?
> Right now, if there are multiple error messages to be output by the
> <struts:errors> tag, they will be separated by newlines. This means they
> effectively run together when displayed in an HTML page. Unless I'm
missing
> something, any formatting has to be included within the messages
themselves.
>
> What about extending ErrorsTag to use an errors.format value as well as
> errors.header and errors.footer, where this string would be used with
> MessageFormat? This would allow much more control over the presentation.
For
> example, with the following values:
>
> errors.header="<table>"
> errors.format="<tr><td>{0}</td></tr>"
> errors.footer="</table>"
>
> the errors would be displayed as a table, one row per error message.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
>
>
>
Re: Elements vs. Attributes in example action.xml
Posted by Pierre Métras <ge...@sympatico.ca>.
Is it a telepathy exercise?:-)
Pierre
----- Original Message -----
From: "Robert Leland" <Ro...@freetocreate.org>
To: <st...@jakarta.apache.org>
Sent: Tuesday, September 26, 2000 10:41 AM
Subject: Elements vs. Attributes in example action.xml
> F
>
Elements vs. Attributes in example action.xml
Posted by Robert Leland <Ro...@freetocreate.org>.
F
Elements vs. Attributes in example action.xml
Posted by Robert Leland <Ro...@freetocreate.org>.
I
Re: An enhancement for ?
Posted by Chris Miller <ki...@vardus.com>.
Even better than that would be to write a <struts:listErrors> tag that would
iterate over the errors.
That way any arbitrary formatting could be applied, on a case-by-case basis
if so desired. Also, it would be nice to remove the HTML from the properties
file - I really don't think it belongs in there.
eg.
<struts:listErrors error="error" count="count">
<font color="red"><%= error %></font><br>
</struts:listErrrors>
<% if (count > 0) { %>
<p/>Please correct the above problems before continuing
<% } %>
The above code would problably be put in a separate file and included using
<struts:include>.
What do you think?
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, September 21, 2000 5:27 AM
Subject: An enhancement for <struts:errors>?
> Right now, if there are multiple error messages to be output by the
> <struts:errors> tag, they will be separated by newlines. This means they
> effectively run together when displayed in an HTML page. Unless I'm
missing
> something, any formatting has to be included within the messages
themselves.
>
> What about extending ErrorsTag to use an errors.format value as well as
> errors.header and errors.footer, where this string would be used with
> MessageFormat? This would allow much more control over the presentation.
For
> example, with the following values:
>
> errors.header="<table>"
> errors.format="<tr><td>{0}</td></tr>"
> errors.footer="</table>"
>
> the errors would be displayed as a table, one row per error message.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
>
>
>