Re[4]: An enhancement for ?

[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