Re[2]: thought on design

[Oleg V Alexeev <go...@penza.net>]

Hello Pierre,

Wednesday, November 22, 2000, 5:48:06 PM, you wrote:

PM> Neg wrote:
>> Now the strings that the validate function returns should identify which
>> parameter has failed validation, perhaps in say this format...
>>
>> parametername/error.text.key
>>

PM> Have a look at the new ActionError and ActionErrors classes in version 1.0.
PM> Though there's not yet an accompanying tag to display specific errors, they
PM> do what you've described:

PM> You have to write your "validate" method like this:

PM> public ActionErrors validate(ActionMapping mapping,
PM>                              javax.servlet.http.HttpServletRequest request)
PM> {
PM>     ActionErrors errors = new ActionErrors();

PM>     if (!validA(fieldA))
PM>     {
PM>         errors.add("fieldA", new ActionError("classX.fieldA.notValid"));
PM>     }
PM>     ...
PM>     return result;
PM> }

How would it be written to browser?
As "fieldA" - <error message from locale package> ?
Or i18n can be applied to field name too?

>> When processValidate calls validate on the ActionForm, it can check to see
>> if any of the failed validations are on the same page as the one that was
>> just submitted. If so, redisplay the form with the errors *for just this
>> page*.
>>
>> If there are no errors on this page, then there is a choice of 2 things
>> depending on what the user requested.
>>
>> 1) If the user has requested 'submit the whole form', then take the user
>> back to the page with errors in it.
>>
>> 2) If the user has request to move to a different page in the form, then
>> allow them to do this and if the page they are moving to has validation
>> errors, then display them.

PM> I've not tried it, but when the "processValidate" fails, it tries to return
PM> to the input form, setting the errors in the request. From there, you should
PM> be able to take this kind of decision. You can find which fields have errors
PM> and decided then on which page you want to redirect the user.

PM> Just like the discussion on global/local validation, I don't think you can
PM> factorize a general behavior for error processing. Suppose -- that's a crazy
PM> example -- that you have a login form with 2 pages: one for the login name
PM> and the other one for the password. If the validation fails, should the code
PM> decide to present the login or the password page? Only you can take the
PM> decision to include business rules like "the user must clear the password if
PM> he wants to change his login name".

PM> Pierre Métras

-- 
Best regards,
 Oleg                            mailto:gonza@penza.net

Re[4]: thought on design

[Oleg V Alexeev <go...@penza.net>]

Hello Pierre,

Wednesday, November 22, 2000, 6:10:27 PM, you wrote:

PM> Hi Neg,
>> PM>     if (!validA(fieldA))
>> PM>     {
>> PM>         errors.add("fieldA", new
PM> ActionError("classX.fieldA.notValid"));
>> PM>     }
>> PM>     ...
>> PM>     return result;
>> PM> }
>>
>> How would it be written to browser?
>> As "fieldA" - <error message from locale package> ?
>> Or i18n can be applied to field name too?

PM> "fieldA" is a constant key to map errors in the ActionErrors collection, so
PM> you can decide what to do with them.
PM> "classX.fieldA.notValid" is a key to find the appropriate error message in
PM> your resource file (i18n applied).

PM> There's no way for now to render the error to the browser. What is missing
PM> is something like <form:error name="fieldA" /> that would display the
PM> associated error message on your form. You can try to write it and propose
PM> your code for 1.0 inclusion...

PM> Pierre Métras

I already have one.. 8)) It takes parameters -
 name - name of attribute with errors
 property - source of error message
 key - key to retrieve message from resource bundle
 
ErrorTag uses ActionErrorsExt - I post this class some hours ago, with
the classes for extended errors rendering.

-- 
Best regards,
 Oleg                            mailto:gonza@penza.net

Re: Re[2]: thought on design

[Pierre Métras <ge...@sympatico.ca>]

Hi Neg,
> PM>     if (!validA(fieldA))
> PM>     {
> PM>         errors.add("fieldA", new
ActionError("classX.fieldA.notValid"));
> PM>     }
> PM>     ...
> PM>     return result;
> PM> }
>
> How would it be written to browser?
> As "fieldA" - <error message from locale package> ?
> Or i18n can be applied to field name too?

"fieldA" is a constant key to map errors in the ActionErrors collection, so
you can decide what to do with them.
"classX.fieldA.notValid" is a key to find the appropriate error message in
your resource file (i18n applied).

There's no way for now to render the error to the browser. What is missing
is something like <form:error name="fieldA" /> that would display the
associated error message on your form. You can try to write it and propose
your code for 1.0 inclusion...

Pierre Métras