RE: DispatchAction role
Thanks for the reply Rick. The reason for my #2 submitForm() method is to handle the validation of the form submission within the same Action as the setup and update methods. This way everything is contained within one Action for a specific JSP form rather than the typical cross-pollination of the next Action handling the previous form's validation. I should have also mentioned that this implementation is being used in a wizard type of application where there are several steps chained together to collect data. Shane -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 10:52 AM To: Struts Users Mailing List Subject: Re: DispatchAction role On Fri, Jul 18,'03 (10:49 AM GMT-0400), Rick wrote: > > 1. init() - sets up the form with initial values for select lists, > > etc. 2. submitForm() - handles the validation and data associated > > with the completed form setup above and forwards to another > > DispatchAction's init() method. > > I do exactly that, and think it's fine. I often have a > > setUp() > update() > display() > Although I should comment that I haven't ever had a need to do your #2 above (forwarding to another dispatch action). I generally don't like to forward my actions to other actions (I'm not in the camp that would say 'never' do it... I just haven't found a need to yet). -- Rick - 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]
Re: DispatchAction role
On Fri, Jul 18,'03 (10:49 AM GMT-0400), Rick wrote: > > 1. init() - sets up the form with initial values for select lists, > > etc. 2. submitForm() - handles the validation and data associated > > with the completed form setup above and forwards to another > > DispatchAction's init() method. > > I do exactly that, and think it's fine. I often have a > > setUp() > update() > display() > Although I should comment that I haven't ever had a need to do your #2 above (forwarding to another dispatch action). I generally don't like to forward my actions to other actions (I'm not in the camp that would say 'never' do it... I just haven't found a need to yet). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction role
On Fri, Jul 18,'03 (09:22 AM GMT-0400), Witbeck, wrote: > Is there any disadvantage of to letting a DispatchAction handle both > the setup and submission of a form something like the following: > > DispatchAction contains the following methods: > > 1. init() - sets up the form with initial values for select lists, > etc. 2. submitForm() - handles the validation and data associated with > the completed form setup above and forwards to another > DispatchAction's init() method. I do exactly that, and think it's fine. I often have a setUp() update() display() works for me:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DispatchAction role
Is there any disadvantage of to letting a DispatchAction handle both the setup and submission of a form something like the following: DispatchAction contains the following methods: 1. init() - sets up the form with initial values for select lists, etc. 2. submitForm() - handles the validation and data associated with the completed form setup above and forwards to another DispatchAction's init() method. This is a re-post but since no one responded I made my post a little more concise this time. Any suggestions or opinions on this is much appreciated. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
