On Thu, 3 Jan 2002, Dimitri Valdin wrote:
> Date: Thu, 3 Jan 2002 10:48:50 +0100
> From: Dimitri Valdin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Errors handling
>
>
>
>
>
> Datum: 03.01.2002 00:33
> An: Struts Developers List <[EMAIL PROTECTED]>
>
>
>
>
> Antwort an: "Struts Developers List" <[EMAIL PROTECTED]>
>
> 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.
OK ... sorry, I didn't get it the first time.
The idea of throwing application exceptions is brand new, so it would be
worth rethinking the example program's factoring in the light of this
ability.
> 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.
>
That's true in the current environment, because we've made token checking
the responsibility of the Action. It could be made the responsibility of
the container instead (presumably only if the token is actually present),
in which case we could do the token check first. Would that make sense?
> 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.
>
Of all the stuff that is in Struts, error handling is the part I'm the
least happy with :-(. This kind of suggestion is worth considering.
> 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.
I also wanted to get the declarative exception stuff into the nightly
builds *before* I started working on the "multiple sub-applications"
problem, which I'm about three quarters of the way through.
>
> Dmitri
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
