struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimitri Valdin" <dimitri.val...@db.com>
Subject Re: Errors handling
Date Thu, 03 Jan 2002 09:48:50 GMT




Datum:         03.01.2002 00:33
An:            Struts Developers List <struts-dev@jakarta.apache.org>




Antwort an:    "Struts Developers List" <struts-dev@jakarta.apache.org>

Betreff:       Re: Errors handling
Nachrichtentext:


Craig,

>> What do you think about extending of Action.execute() with errors parameter ?
>> At that case ActionServlet will take care about saving of errors in HttpServletRequest
and
>> errors won't get lost in case some exception occurs and they were not saved yet.
>>
>> Craig, why don't you want to handle "error.password.mismatch" as exception,
>> but add error manually ? I think, that the check user.getPassword().equals(password)
>> should be done somewhere deep in code, perhaps in EJB or realm but not in Action
class.
>> You have probably some reasons doing this.


>In my view there will often be validations that are performed at various
>levels (inside the client, as part of the form bean's validate() method,
>and by the business logic tier).  In this particular case, you typically
>can't validate the password inside the form bean's validate() method --
>that would take interacting with the business logic being used to
>represent your user database.  That's why I treated this one separately,
>and did the check in the Action (which would usually be done by a database
>query or directory server lookup in a real application).

>The validate() method *does* check for the fact that both the username and
>password are required -- that's something you can check without
>interacting with the business logic tier.

Exactly. But I was talking not about validate method, but about throwing
of AppException("error.password.mismatch") in a business logic layer.
In LogonAction.getUser() in our simple example. I have implemented it in this way,
therefore I am curious, why did you change that.
The ExceptionHandler class would store an appropriate ActionError in
request / session automatically. That was the reason, why I have asked
about extension of Action.execute() with "errors" parameter.
Even if exception occures, errors will be prevented and ExceptionHandler
can just add a new ActionError into this list. User won't need to call
saveErrors excplicitely, since it can be done in ActionServlet.

I prefer not to use a validate() method at all. In case you check for
transaction token, this check can be done only after validate method
brings no errors. It would mean, that user has to correct all mistakes
which are checked in validate() and then will receive a message that
he is out of the transaction. Correct me if I wrong.

In case of big formulars with lot of fields, it would look pretty ugly
to have "please fill in field1",  "please fill in field2", etc.
What about of introducing the list of "must" fields, and handle this
situation in struts, by creating an ActionError "error.fill_in_all_requeired_fields" ?
Of cource, the validation framework can do more, but this is a struts extention.

BTW, thanks for checking in the declarative exception stuff. There were couple
of things which should be implemented in a bit other way, like instantianting
of error handler and all changes, referring to multiple struts configs,
but I just wanted to produce a first working version

Dmitri









--

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie
nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.



--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message