There are a number of ways to achieve this, and again (!) it's about choice, although
I must say this can be confusing for newbie (and experienced!) struts users.
1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.
Option 3 is basically an added method to the ActionForm class that allows the Action
to determine if 'pre' or 'post' processing the form, without the need for an 'action'
parameter. Consider the following in the Action class, where 'sf' refers to the
instance of the form:
// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);
// getting this far indicates post-processing...
/**
* Determines if pre or post processing the form.<br>
* Criteria being null indicates pre-processing.
*
* @return true if pre-processing the form
*/
public boolean isVirgin () {
return ( (criteria == null) );
}
The 'isVirgin' method returns true if 'pre' processing the form, and false if 'post'
processing.
Option 1 gives good seperation, but can lead to an unneccesary proliferation of Action
classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post processing in the
one Action - however, this doesn't extend as far as seperate actions and action
parameters when you need to do more than just pre and post processing.
In our applications we have used all 3 at various times. We tend to use option 3 when
we just need the split between pre and post processing, eg a Search or Login action.
In more complex sceanrio's we tend to use option 1 or 2.
Try to determine which best fits your scenario. Depending on your context, one
solution may be better than the other, but this will not be true across the board for
all scenarios. Think through your real needs before choosing the solution.
With regards to your exact scenario, we developed option 3 as a solution to this very
situation, so I would suggest option 3 might be best suited, although you will
ultimately have to decide ! Having developed option 3 and implemented it, we have
found it to be the most effective way of getting around this. As I previously stated,
option 1 and 2 come into their own in other situations.
Hope this helps - if you need any more detail let me know,
Ghoot
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 February 2002 17:10
> To: Struts Users Mailing List
> Subject: Struts design question about maintenance screens
>
>
>
> Hi Folks:
>
> thanks to your help, you indicated that the Action should preload form
> values on a maintenance form. This works great.
>
> I have an Action object that allows maintenance on a table
> (call it table
> A). This action object handles "preloading of data"
> as well as the actual "updating of data" (Add/Edit/View).
>
> Another question I have:
> - The action object gets kind of "kludgey" in how I have to
> keep track of
> "whether I am preloading data (called from a html:link)" or
> whether I am
> "Applying" the data (called from the form Submit).
> Is it "overkill" if I create 2 different actions (1 action to
> preload the
> data and another to "update" the data)? I think by doing
> it this way, it
> may be easier for me to incorporate the "sensitive form resubmit"
> prevention by using tokens.
>
> Any suggestions are much appreciated.
>
> thanks,
> Theron
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
