You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Josh Berry <jo...@usa.net> on 2002/10/29 19:33:40 UTC

Re: [how many form for update and create action ?]

"Xavier Combelle" <xc...@kaptech.com> wrote:
>I have a conceptual problem in my struts application
>
>I am programming an application which give the possibility
>to create, update and delete several information, for exemple 
>the name and the price of an item.
>
>So I need to give to the user two possibilities :
> 1- the possibility to create an item
> 2- the possibility to update an item
>so i use two action, one for each possibility
>
>Should I use the same form bean to update and create or
>should I use different form bean, one for update and one for create ?
>and if I should use different form bean, should they have the same type ?


I can only explain my approach.  For simplicity, I will change it to a User
example.  

I have one form for all user related information.  However, there are three
places that this information will be used, specifically, there is a search
page, an add page, and an edit page.  So, I created a pre-action that handles
each of these pages.  (note, they all use the same preaction)

The pre-action simply makes sure that the form is initialized correctly.  In
the case of the edit page, it loads the user to be edited.

The search page submits to a particular action for searching, though the add
and edit page both submit to an action for saving.  I was able to distinguish
which page linked to the action based upon the parameter.

So... for at least three input pages, I have one form and a total of three
actions.  Of course, saying it like that sounds like I simply wanted to
minimize the number of files to create.  Possibly, but it really does feel
simpler this way.

That is the way I would recommend it, one form.  Some pages are just subsets
of the form, but you still just need the one form.  Afterall, the whole point
of the form class is simply a buffer between the presentation and the business
logic.  It should reflect more of what the user is going to experience then
what the backend knows.

Now, before you take my word, I would at defer to others here.  If people
would chime in on my approach I would greatly appreciate it.

-josh


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>