If your implementation is similar to what Scott has mentioned (i.e. different operations on the same type of object), then I consider this a classic example of a DispatchAction, where type of business entity doesn't change...just the selected operation on the business entity, thus it makes sense to have it in the same action.
On 6/21/06, Scott Van Wart <[EMAIL PROTECTED]> wrote:
Kavita Mehta wrote: > > Hi, > I have a form which has 3 submit buttons . > which is a gud ides ... > 1) having seperate 3 action classes for each > 2) having a single action class which manages the submit action based > on the button which has called this action class. It's up to you ;). I typically divide things into multiple actions (and possibly forms) when the form data is different. So, if I had a record-editing page where you can: 1) Update the record you're currently editing. 2) Create a new record from the data you've entered. 3) Delete the record you're currently editing. I'd have 2 actions, and 1 form: /saveRecord (recordForm) -> SaveRecordAction.execute /deleteRecord (recordForm -- only uses the record key) -> DeleteRecordAction.execute You can inspect the button value returned to determine the button clicked in a single form. Have fun, Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
