Craig and Mark, Thanks a lot for pointing out the "Preparable" interface. I think that solves a major problem with Struts 1. I'm yet to experiment heavily with WW/Struts 2, but I feel like the "Interceptor" concept is a very powerful approach, though a bit dangerous if not well controlled.
Craig, We, actually, decided that we don't want to get into JSF yet. But if this "prerender" method is equivalent to the "onPageLoad()" method in ASP .NET, then it's a very important piece that is really missing from the JSF spec. Yujun, Your idea is brilliant and it never crossed my mind. If we stick with Struts 1, I think I will try that. Christopher, I really wonder if the Struts you're talking about is the one I've using for years now!! The Struts I know sucks big time when it comes to action chaining. I'm afraid I don't understand how defining two mappings, one with validation turned on and the other turned off, solves the first problem! As for the second problem, your solution still involves action chaining which should be avoided unless you've done something equivalent to what Yujun did. Thanks everyone for your help. -----Original Message----- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 5:36 PM To: Struts Users Mailing List Subject: Re: Does Struts 2 solve the action chaining problem? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek, Tarek Nabil wrote: > One of the problems with Struts was that if you had a page that requires > some setup and this page submits to an Action, then you would not be > able to set validate to true on that action because if validation > problems occur then Struts will take you directly to the input JSP > without performing the setup and your JSP wouldn't work. > > A solution to that would be to specify the input of the action as the > setup action, which means you're doing action chaining and Struts is not > good at that (it will reset your form among other things). > > The solution of choice for us so far was to call validate() ourselves in > the action and if a validation problem occurs then we call the setup > method (eventually you start using your action methods as an API which > still was not good). I totally disagree. If you have an action that you want to use like this, you can always set up two different mappings -- one that /does/ validate and another that does /not/ validate. My experience has been that Struts is very good at "action chaining"... in fact, that's the major advantage of Struts in the first place: the ability to map URIs to actions and specify their relationships through forward mappings. > Another problematic scenario is the case when you're editing some > database record for example. When you go to your setup action for the > first time, you will populate drop down lists for example, and then load > the existing values from the database to your JSP fields. If the user > attempts to save and some problem occurs then in the setup action, you > will need to again populate the drop down lists, but you will NOT want > to overwrite the user's inputs with the existing data. This is very > similar to the first problem, but you would also need to pass some flag > to the setup method to tell it whether to copy the data from the > database to your ActionForm. In this case, what you want is something like: LoadAction -> EditAction -> Display form Form submits to SaveAction, which has EditAction as input (not LoadAction). This is pretty standard stuff, and works beautifully. > Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I really hope so, since Struts 1.x also does. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbYyx9CaO5/Lv0PARArpHAJ0U3fHybMWepSZxPjciDU3+6M2PwQCgoy8B FRlfdQsyONpgqGvrHBuZuFw= =EbD/ -----END PGP SIGNATURE----- ********************************************DISCLAIMER******************************************** This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof. If you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change.The sender shall not be liable for the improper or incomplete transmission of the information contained in this communication,nor for any delay in its receipt or damage to your system.The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. ************************************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
