Craig,
>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. We use such approach even for exceptions which are "thrown" by host's Cobol programs and it works well. Of cource they are wrapped within XML stuff. But you are right. If we really decide to use them in struts-example, then we should perform refactoring for the whole example. >> 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? Sure. > 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. If you have nothing against, I will create a new Bugzilla entry with some proposals, concerning errors handling, so we can discuss it one day. >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. That's nice. 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
