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...-tf4391572.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]
