Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 11632 invoked from network); 3 Jan 2002 09:45:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Jan 2002 09:45:17 -0000 Received: (qmail 15987 invoked by uid 97); 3 Jan 2002 09:45:23 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@jakarta.apache.org Received: (qmail 15952 invoked by uid 97); 3 Jan 2002 09:45:22 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 15940 invoked from network); 3 Jan 2002 09:45:21 -0000 Subject: Re: Errors handling X-Priority: 3 (Normal) To: "Struts Developers List" From: "Dimitri Valdin" Date: Thu, 3 Jan 2002 10:48:50 +0100 Message-ID: X-MIMETrack: Serialize by Router on sdbo1001/Eschborn/DeuBaInt/DeuBa(Release 5.0.8 |June 18, 2001) at 01/03/2002 10:45:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Datum: 03.01.2002 00:33 An: Struts Developers List Antwort an: "Struts Developers List" = Betreff: Re: Errors handling Nachrichtentext: Craig, >> What do you think about extending of Action.execute() with errors pa= rameter ? >> 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 no= t saved yet. >> >> Craig, why don't you want to handle "error.password.mismatch" as exc= eption, >> 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 n= ot in Action class. >> You have probably some reasons doing this. >In my view there will often be validations that are performed at vario= us >levels (inside the client, as part of the form bean's validate() metho= d, >and by the business logic tier). In this particular case, you typical= ly >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 separatel= y, >and did the check in the Action (which would usually be done by a data= base >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 throwin= g of AppException("error.password.mismatch") in a business logic layer. In LogonAction.getUser() in our simple example. I have implemented it i= n 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 ExceptionHandle= r 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_requ= eired_fields" ? Of cource, the validation framework can do more, but this is a struts e= xtention. BTW, thanks for checking in the declarative exception stuff. There were= couple of things which should be implemented in a bit other way, like instanti= anting 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=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Inf= ormationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail= irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender= und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbef= ugte 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 err= or) please notify the sender immediately and destroy this e-mail. Any u= nauthorized copying, disclosure or distribution of the material in this= e-mail is strictly forbidden. = -- To unsubscribe, e-mail: For additional commands, e-mail: