Another drawback of Option 1 is that if your jsp's change frequently (adding fields in the form, different formatting etc.) having two jsp's requires you to update two files. This is not a problem in itself but it might make for more difficult maintenance because you might make changes on one jsp but forget the other. Just another thing to consider when you make your design choice.
Option 3 sounds attractive. Thanks for the idea, Emaho. JC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 12:09 PM To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: RE: Struts design question about maintenance screens Wow! Great reply. I am saving this one. thanks, Theron "Emaho, Ghoot" <Ghoot@PETROTECHN To: Struts Users Mailing List <[EMAIL PROTECTED]> ICS.co.uk> cc: Subject: RE: Struts design question about maintenance screens 02/21/02 09:51 AM Please respond to Struts Users Mailing List 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]> -- 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]>
