Hi Al, I am having the same problem with s:select and validation. I found your thread when I searched the user group for answers.
Have you found a better solution to this problem? Has it be identified as a bug? Unfortunately, I am so far along on my validation code that I really don't want to simply turn it off. Is there a way to rearrange the interceptor so that validation can still be used? I'd appreciate any update you have on this issue. Thanks, Jane -----Original Message----- From: Al Sutton [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 12:45 PM To: 'Struts Users Mailing List' Subject: RE: [s2.0.9] Is there a better way to do this... Ok, Looks like the first part is confusion in terminology. I took Action to mean an action as defined in struts.xml, but I now see Richard meant a single class used to declare two actions. Your solution to the second part doesn't seem right to me. My understanding of things is that if struts validation was enabled and it failed validating one of the form parameters the submit method would not get called and thus the list would not be re-populated before the user is sent back to the input page. So it isn't right for me because I'm looking for something which allows action message passing between actions and allows validation to be enabled. Thanks for the suggestion though. -----Original Message----- From: cilquirm [mailto:[EMAIL PROTECTED] Sent: 06 September 2007 16:32 To: user@struts.apache.org Subject: RE: [s2.0.9] Is there a better way to do this... Al Sutton-4 wrote: > > Hi Richard, > > Thanks for the pointer. > > I'm using 2 actions because my current belief is that using a single > action would cause problems with result names because you can't define > separate SUCCESS results for the form prep and the form submission if > you only have one action (or have I misunderstood the docs?). > > You can have a single action with multiple execution methods that return the same result name to different result values. i.e. public class MyAction extends ActionSupport { public String prep() { ... return SUCCESS; public String submit() { ... return SUCCESS; } } could be defined as <package name="my-package" namespace="/form"> <action name="prep" class="my.package.MyAction" method="prep"> <result name="success">/my/dir/myjsp1.jsp</result> </action> <action name="submit" class="my.package.MyAction" method="prep"> <result name="success">/my/dir/myjsp1.jsp</result> </action> </package> Al Sutton-4 wrote: > > > Isn't using the Prepareable interface on the submission action > inefficient?, I can see it's an option for the list population action, > but wouldn't the database be queried unnecessarily when the form is > submitted with no errors > because the action class gets the list from the database in the prepare > method? > > Al. > > I think what Richard is suggesting is something akin to this : public class AwesomeAction extends ActionSupport implements Preparable { List awesomeList; AwesomeService awesomeService; public void prepare() { awesomeList = awesomeService.getList(); } public string prep() { return SUCCESS; } public String submit() { [ do checks ] if ( !everythignChecksOut ) return INPUT; return SUCCESS; } } In such a scenario, yes, prepare would be called on the submission. You can work around it in this manner. public class AwesomeAction extends ActionSupport implements Preparable { List awesomeList; AwesomeService awesomeService; public void preparePrep /* how droll! */ () { awesomeList = awesomeService.getList(); } public string prep() { return SUCCESS; } public String submit() { [ do checks ] if ( !everythignChecksOut ) { preparePrep(); return INPUT; } return SUCCESS; } } HTH, -a Al Sutton-4 wrote: > > > > -----Original Message----- > From: Richard Sayre [mailto:[EMAIL PROTECTED] > Sent: 06 September 2007 13:33 > To: Struts Users Mailing List > Subject: Re: [s2.0.9] Is there a better way to do this... > > > I use the prepare method to populate my lists. See the Prepareable > interface. I also would put this in Action B. Is there a specific > reason why you are using 2 actions? > > On 9/6/07, Al Sutton <[EMAIL PROTECTED]> wrote: >> Here's a problem I've come across a couple of times and the solution >> I >> have feels clunky so I thought I'd throw it out to see if anyone has >> any better ideas; >> >> I have a form which has a s:select populated from a Map of objects >> which come from a database, at the moment I'm doing the following; >> >> 1) Action A gets the list from the database >> 2) A .JSP displays the form with the s:select and submits to Action B >> 3) Action B processes the form. >> >> This is looks neat until you look at the situation when an error >> occurs. >> >> In order to ensure that the s:select is correctly filled the error >> result has to send the browser back to Action A, which is being done >> as a redirect. The problem with this is that all actionMessages and >> actionErrors get lost during the redirect, and thus the user can't see >> what was wrong. To get around this I use the store interceptor, but >> this causes problems if validation is turned on (it will bounce the >> user to the error result of Action A if an errorMessage is present - >> see https://issues.apache.org/struts/browse/WW-1963 for the bug >> report). >> >> So I end up with the validation interceptor turned off and having to >> hand code some validation, and the store interceptor turned on for >> several actions. >> >> So has anyone found a better way of handling the "populate list -> >> show list >> -> handle errors" situation? >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-s2.0.9--Is-there-a-better-way-to-do-this...-tf439 1572 .html#a12525108 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
