You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Vikrama Sanjeeva <vi...@gmail.com> on 2005/12/25 13:05:56 UTC
pre-populating form fields when called in edit mode.
Hi,
Here is the sequence:
1: User fill up's "employeeForm.jsp" which have multiple text fields, radio
buttons, text area's and dropdowns.
2: On pressing "Submit" button in "employeeForm.jsp", "InsertEmployeeAction"
is called which do the following:
2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
2.2) DataBaseService.insertEmployee (employeeDTO)
2.3) return mapping.findForward("success");
Now, I want to call same "employeeForm.jsp" in "editable" mode, such that
all the fields (text fields, radio buttons, text area's and dropdowns) are
"pre-populated". What approaches are there to achieve this? I'm looking for
a way which uses same BeanUtils.copyProperties() and copy the employeeDTO
to employeeForm (Bean). Something like this:
When user click's "Edit Employee Form" link, an action
(EditEmployeeAction) will be called. Which will do the following:
1. Fetch the employee information from database in employeeDTO.
2. Get the "handle" of EmployeeForm (ActionForm), lets say "employeeForm"
3. BeanUtils.copyProperties(employeeForm, employeeDTO)
4. return mapping.findForward("editMode");
I'm not sure whether this approach will work or not? And whether I have to
make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode (
employeeFormEdit.jsp). If this the case, then I guess, I've to make
EmployeeFormEdit.java (ActionForm) as well.
It will be great if anybody could help me here.
Thanks in advance.
Bye,
Viki.
Re: pre-populating form fields when called in edit mode.
Posted by Rick Reumann <ri...@gmail.com>.
On 12/26/05, Paul Benedict <pa...@yahoo.com> wrote:
>
> >>I would use the Request for such a List and wouldn't even bother putting
> it in the ActionForm
>
> But that of course doesn't make the list persist. Most frameworks heavily
> rely on the user session
> and I am now a strong believer that's the better way of doing things.
I think it depends on the kind of list and each person may have their own
preference. For example, I personally would reather persist on the backend
with iBATIS or hibernate vs just stuffing things in the Session. For
example, what if it's just one form that needs the list and the user only
hits the form one time during the whole time using the site? You've now just
just stuff a list in Session scope for what gain? If it's a list that
actually will *never* change than put in Application scope. I don't see the
point of putting most lists in Session scope. For struts apps most people
end up stuffing lists in Session scope so that if validation fails their
lists persists on the page. I don't call the validate method manually so I
don't run into this problem. Also remember we are talking about "lists"
here. Don't think I'm against the Session (if you do a mailing list search
you'll see I love the Session maybe too much:)
If I remember correctly, I know you promoted a solution of using the
> validate() method of
> containing those populated lists. That's on the right track but I think a
> misuse of the validate()
> method.
Actually you are remembering incorrectly:) I'm assuming you are referring to
this article http://reumann.net/struts/articles/request_lists.jsp, but there
I stated exactly the OPPOSITE - that you SHOULD NOT use the validate method
for setting up those lists. I said I "do validation manually." I did show
how you can simply call the form's validate method manually (even though I
don't even go that far in my own apps), but I never mentioned it's a good
idea to set up lists in your validate method.
Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that
> is called
> before executing mostly everything else.
JSF is great at handling all of this as well so don't leave JSF out.
I try to keep my ActionForm with 'only' properties that the user can edit -
> nothing more.
>
> Ahhhhh! You and I really chatted this up a year ago. I was gung-ho for
> this method, but no longer.
> I was a very die hard proponent of this but I could only go so far with
> it; the problem was it
> made no logical sense to contain some data in the form (which was then put
> into the request) and
> then some data in the request. Both end up in the request, so why separate
> the two? It did not
> allow me to encapsulate my data --- and it created a very difficult
> nightmare to track down which
> request attributes were appropriate for a given form. So in response, I
> concluded this method was
> good up to a point, but everything in the action form suited more complex
> cases.
Well think about it this way, JSF has it right in that it eliminates the
need for an ActionForm. It let's you use your regular Value objects which I
think is great (I hate the Struts ActionForm:). JSF gets around the Lists
problem, though, by taking a whole different model approach which has been
talked about enough on the list here but I do like how JSF handles this.
(That being said, there are some things I have found frustrating using
JSF(MyFaces) so I'm not ready to jump ship yet.)
What
> seemed like a good solution back then turned out to be the best at that
> time; now I think
> everything in the form is a better performing car.
I only have one "prep" method in my Action so anything that needs to get
setup in a form goes in that one place and can be called from the other
dispatch methods in the Action. I like the approach since it is easy to
maintain. I don't really see what putting the Lists in your ActionForm gains
you? You are still going to have to populate them from method calls to other
backend objects. Even then, I would think you'd want to use a prep method
for that as well since you might need to prep those lists in your form from
several dispatch methods. I'm not so sure how doing... form.setSomeList(list)
gains you anything over request.setAttribute(Constants.SOME_LIST, someList
); especially if both types of setting is done from a centralized place in
your Action. Then again, I'm of course not saying it's bad or wrong to put
the stuff in the ActionForm (I even like approaches where nest your value
object in the ActionForm). Overall though, I'm just not a fan of having to
be stuck using ActionForms in the first place, so I try to avoid as much
dependency on them as possible (I really do like the managed bean approach
of JSF which handles this stuff so nicely).
--
Rick
Re: pre-populating form fields when called in edit mode.
Posted by Paul Benedict <pa...@yahoo.com>.
>>ActionForm should be removed from session manually, this is the price to pay. I thought about
automating this, but Hubert pointed out that a user can open several browser windows for one app,
so I gave up on this.
One of the biggest concerns I had too was that using the session means only one form can exist per
session. So if the user had multiple windows open, it would completely mess things up. So I was
for 2 years against making any forms in the session -- until Tapestry woke me up =)
It is now my opinion that any complex web app form will have BO, DTOs, and lists all together.
This merits only ONE of these being editable at once. Got multiple windows open? Sorry user, but
you're not going to be able to use my app. Spring Framework's Web Flow is an excellent plugin for
these situations; it allows multiple flows until the first one wins.
I just had to accept the fact that until Struts allows forms to exist on a per-view basis, the
best a complex app can do is limit one form to the session. Simple forms can be request based, but
anything editable (and worthwhile to the customer) definitely has to be session.
Paul
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Michael Jouravlev <jm...@gmail.com>.
I guess it is not surprising that I would do a completely orthogonal thing ;-)
ActionForm is an I/O buffer, it aggregates BO/DTO + lists/options for
selectboxes + error messages for the aggregated BO. BO exposes
properties that are editable and "persistable". BO does not care about
option lists because actual BO or database row contains only one
value. BO is a nested property within session-scoped ActionForm.
Whenever error is made and page is reloaded, or a user just navigates
a page, it displays BO in its current state and associated messages.
ActionForm should be removed from session manually, this is the price
to pay. I thought about automating this, but Hubert pointed out that a
user can open several browser windows for one app, so I gave up on
this.
Storing list in the session (session-scoped ActionForm,
poteito-potahto) also helps in case the option list itself was changed
down on the business/persistent level, so a new instance in request
would not match previous one, and current selection would get screwed
up.
Actually, if the option list is changed very rarely, I'd put it into
app context. If it is changed more frequently, then into session
scope, to isolate user session from potential changes.
Michael.
On 12/26/05, Rick Reumann <ri...@gmail.com> wrote:
> I would use the Request for such a List and wouldn't even bother putting it
> in the ActionForm (unless of course the list is something the user is
> actually editing, then yes, you'd add that List as an ActionForm property).
> I try to keep my ActionForm with 'only' properties that the user can edit -
> nothing more. So for example if you were displaying a list of favorite cars
> for the user to pick from I would just put that list in the Request and the
> "selectedCar" would be the property you would concern youself with in the
> ActionForm. (If you are worried about performance, I'd put the performance
> concerns on the backend.. let the back end take care of any list caching.)
>
> On 12/26/05, Paul Benedict <pa...@yahoo.com> wrote:
> >
> > I am going to ask a related question... so take your best shot :-)
> >
> > I have an edit form in which I have to load a list from the database. The
> > list is actually based
> > on locale. What's the best solution here? I am using real action forms -
> > not that dynafluff stuff
> > ;) Is it to simply make my form session scope and attach the list to my
> > form?
> >
> > THANKS!
> > Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Paul Benedict wrote:
> But that of course doesn't make the list persist. Most frameworks heavily rely on the user session
> and I am now a strong believer that's the better way of doing things.
Just as a relevant side-note...
I suggest working in a distributed environment for a while and see if
your belief persists (pun intended) :)
Session replication, especially when your session object grows larger,
as they obviously will tend to in a session-heavy framework, becomes
more and more of a concern. I seem to remember IBM recommending
something like a 32k maximum for session, although I'm not sure how
accurate my memory is, the point remains that they are recommending a
value that is pretty easy to blow past without much effort.
The concern is obviously not as big when your on a single box, but even
then you need to think about session persistence, if active, which will
still incur a penalty for a larger session.
I think request scope still has a definite place in the world. This
relatively recent movement to heavy session usage still has its own set
of problems. OF course, everyone is trying to make the web more fat
client-like, me included, and that's mostly where this drive towards
session comes from.
It's interesting to me that a fairly short while ago, the use of session
for anything other than *very* simple things was a pretty highly
discouraged practice... I remember Microsoft used to say you should
almost *never* use session (or worse, application scope), everything
should be request-based. Now, I don't think *that* extreme is the right
answer, but it has been a complete 180 (I guess MS isn't the best
example, but your heard very similar recommendations from the Java camp
as well).
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Paul Benedict <pa...@yahoo.com>.
>>I would use the Request for such a List and wouldn't even bother putting it in the ActionForm
But that of course doesn't make the list persist. Most frameworks heavily rely on the user session
and I am now a strong believer that's the better way of doing things. I wonder if allowing the
developer to be concerned with page/request/session/application scope creates a whole problem in
itself; this problem is so unique to Struts and JSP development, but not a thought with Tapestry
or JSF.
If I remember correctly, I know you promoted a solution of using the validate() method of
containing those populated lists. That's on the right track but I think a misuse of the validate()
method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that is called
before executing mostly everything else. I would like to see this ported into 1.3 because with the
ComposableRequestProcessor, you can slam in any cool customization into the processing chain!
I try to keep my ActionForm with 'only' properties that the user can edit - nothing more.
Ahhhhh! You and I really chatted this up a year ago. I was gung-ho for this method, but no longer.
I was a very die hard proponent of this but I could only go so far with it; the problem was it
made no logical sense to contain some data in the form (which was then put into the request) and
then some data in the request. Both end up in the request, so why separate the two? It did not
allow me to encapsulate my data --- and it created a very difficult nightmare to track down which
request attributes were appropriate for a given form. So in response, I concluded this method was
good up to a point, but everything in the action form suited more complex cases.
This is my opinion based on experience. Sometimes I just have to travel down the road far enough
to see how far the solution will take me -- some solutions are 20 gallon cars, others 30, 50. What
seemed like a good solution back then turned out to be the best at that time; now I think
everything in the form is a better performing car.
Paul
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Rick Reumann <ri...@gmail.com>.
I would use the Request for such a List and wouldn't even bother putting it
in the ActionForm (unless of course the list is something the user is
actually editing, then yes, you'd add that List as an ActionForm property).
I try to keep my ActionForm with 'only' properties that the user can edit -
nothing more. So for example if you were displaying a list of favorite cars
for the user to pick from I would just put that list in the Request and the
"selectedCar" would be the property you would concern youself with in the
ActionForm. (If you are worried about performance, I'd put the performance
concerns on the backend.. let the back end take care of any list caching.)
On 12/26/05, Paul Benedict <pa...@yahoo.com> wrote:
>
> I am going to ask a related question... so take your best shot :-)
>
> I have an edit form in which I have to load a list from the database. The
> list is actually based
> on locale. What's the best solution here? I am using real action forms -
> not that dynafluff stuff
> ;) Is it to simply make my form session scope and attach the list to my
> form?
>
> THANKS!
> Paul
>
>
>
>
> __________________________________
> Yahoo! for Good - Make a difference this year.
> http://brand.yahoo.com/cybergivingweek2005/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Rick
Re: pre-populating form fields when called in edit mode.
Posted by Paul Benedict <pa...@yahoo.com>.
I am going to ask a related question... so take your best shot :-)
I have an edit form in which I have to load a list from the database. The list is actually based
on locale. What's the best solution here? I am using real action forms - not that dynafluff stuff
;) Is it to simply make my form session scope and attach the list to my form?
THANKS!
Paul
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Michael Jouravlev <jm...@gmail.com>.
If you treat inserts like updates, things get much easier. When you
show employee in edit mode, just pull his data from database into
BO/DTO and show it. When you add new employee, create a new empty
BO/DTO first. Then show it just like you would do it in edit mode. If
user clicks "Save", insert data. If user cancels, just dispose the
object, this is it.
Michael J.
On 12/25/05, Vikrama Sanjeeva <vi...@gmail.com> wrote:
>
> Hi,
>
> Here is the sequence:
>
> 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> radio
> buttons, text area's and dropdowns.
> 2: On pressing "Submit" button in "employeeForm.jsp",
> "InsertEmployeeAction"
> is called which do the following:
>
> 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> 2.2) DataBaseService.insertEmployee (employeeDTO)
> 2.3) return mapping.findForward("success");
>
> Now, I want to call same "employeeForm.jsp" in "editable" mode, such that
> all the fields (text fields, radio buttons, text area's and dropdowns) are
> "pre-populated". What approaches are there to achieve this? I'm looking
> for
> a way which uses same BeanUtils.copyProperties() and copy the employeeDTO
> to employeeForm (Bean). Something like this:
>
> When user click's "Edit Employee Form" link, an action
> (EditEmployeeAction) will be called. Which will do the following:
>
> 1. Fetch the employee information from database in employeeDTO.
> 2. Get the "handle" of EmployeeForm (ActionForm), lets say "employeeForm"
> 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> 4. return mapping.findForward("editMode");
>
> I'm not sure whether this approach will work or not? And whether I have
> to
> make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode (
> employeeFormEdit.jsp). If this the case, then I guess, I've to make
> EmployeeFormEdit.java (ActionForm) as well.
>
> It will be great if anybody could help me here.
>
> Thanks in advance.
>
> Bye,
> Viki.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
Hi,
Well, i said "better" due to sake of simplicity. Keeping all the logic in
Dispactch action seems complex to me. And right now I've implemented more or
less same technique (not exactly Dispatch action) and the code is bit
complex to me. Again for JSP's, I don't want to make code complex by
putting if-else logic. But it depends how much you have to write if-else? If
it is couple of conditions and more resusability, then I would prefer it
Regarding the word "better", I would suggest don't take it serious. I
said "better" w.r.t me. This is not any claim in support of separate
actions. However, being a junior developer, I'm always looking for effecient
and recommended development approaches by senior developer's community.
Bye,
Viki.
On 12/28/05, Rick R <st...@reumann.net> wrote:
>
> Vikrama Sanjeeva wrote:
> >
> > Having separate Actions for insert, update and delete is better.
>
> Why? Do you make separate DAO objects? ie UpdateDao, InsertDao,
> RetrieveDao? I'm guessing you don't. So, it would help if you backed up
> your claim that separate Actions are better than a Dispatch action
> instead of just claiming it's better.
>
> > Your approch for making SetUpAction is right, but it's better to make
> separate
> > JSP's instead of writing if-else logic for headers and other related
> > messages.
>
> So you would rather duplicate JSPs to make basically identical Edit and
> Insert pages except for a simple header and possibly a different button?
> Please explain how in the world that is "better."
>
> I'm hoping it's just a language barrier that is making you appear so
> dogmatic in your claims. You might choose to do things differently but
> it would help if you gave some reasons why you make such bold claims
> about things being "better."
>
> --
> Rick
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: pre-populating form fields when called in edit mode.
Posted by Rick R <st...@reumann.net>.
Vikrama Sanjeeva wrote:
>
> Having separate Actions for insert, update and delete is better.
Why? Do you make separate DAO objects? ie UpdateDao, InsertDao,
RetrieveDao? I'm guessing you don't. So, it would help if you backed up
your claim that separate Actions are better than a Dispatch action
instead of just claiming it's better.
> Your approch for making SetUpAction is right, but it's better to make separate
> JSP's instead of writing if-else logic for headers and other related
> messages.
So you would rather duplicate JSPs to make basically identical Edit and
Insert pages except for a simple header and possibly a different button?
Please explain how in the world that is "better."
I'm hoping it's just a language barrier that is making you appear so
dogmatic in your claims. You might choose to do things differently but
it would help if you gave some reasons why you make such bold claims
about things being "better."
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: pre-populating form fields when called in edit mode.
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
Hi,
Having separate Actions for insert, update and delete is better. Your
approch for making SetUpAction is right, but it's better to make separate
JSP's instead of writing if-else logic for headers and other related
messages.
Bye,
Viki.
Note: When u'r done with lesson, please sent in this group. Thank you.
On 12/27/05, Rick Reumann <ri...@gmail.com> wrote:
>
> I'm going to have a good lesson that will show exactly what you want, but
> until then, if you want a quick preview of the Action class, put it here:
>
> http://www.reumann.net/misc/EmployeeAction.txt
>
> You are following an example where I showed using a separate Action for
> each
> behaviour whereas the link above shows a DispatchAction. It's just a short
> cut for putting related tasks in one action versus using separate actions.
> Regardless, though, let's assume your separate Action approach which is
> just
> fine.
>
> I typically would make a SetUpAction that you would call "before" you
> forwarded to the JSP page where you would be editing the form. So let's
> assume you went to edit the Employee from a link you clicked on, the
> process
> would be...
>
> 1) Click on link, passing something like an employeeID
> 2) link submits to your SetUpAction
> 3) In SetUpAction it checks the Request to see if an "employeeID" was
> passed
> to it. If ti was, you go database get your Employee object (EmployeeDTO
> following your old example) and then you can use BeanUtils like you did
> before...
> BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings
> you
> to the "employeForm.jsp" page.
> 4) employeeForm is now all set up with the employee information and
> clicking
> 'submit' would bring you to an UpdateEmployeeAction to do the actual
> update
> (just like you did for the InsertEmployeeAction).
>
> You can easily reuse the form for doing both "inserts" and "updates."
> Typically you'll have to do a little bti of logic for some of the verbage
> to
> decide what to display (ie is header "Insert Employee" or "Update
> Employee"). You can base your logic to decide what to display on various
> things (in this case it could be as simple as looking for an "employeeID"
> ..
> if you have one then you know you are doing an update... if you don't than
> you are doing an insert, but of course there are plenty of other ways to
> do
> it as well.
>
> On 12/25/05, Vikrama Sanjeeva <vi...@gmail.com> wrote:
> >
> > Hi,
> >
> > Here is the sequence:
> >
> > 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> > radio
> > buttons, text area's and dropdowns.
> > 2: On pressing "Submit" button in "employeeForm.jsp",
> > "InsertEmployeeAction"
> > is called which do the following:
> >
> > 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> > 2.2) DataBaseService.insertEmployee (employeeDTO)
> > 2.3) return mapping.findForward("success");
> >
> > Now, I want to call same "employeeForm.jsp" in "editable" mode, such
> that
> > all the fields (text fields, radio buttons, text area's and dropdowns)
> are
> > "pre-populated". What approaches are there to achieve this? I'm looking
> > for
> > a way which uses same BeanUtils.copyProperties() and copy the
> employeeDTO
> > to employeeForm (Bean). Something like this:
> >
> > When user click's "Edit Employee Form" link, an action
> > (EditEmployeeAction) will be called. Which will do the following:
> >
> > 1. Fetch the employee information from database in employeeDTO.
> > 2. Get the "handle" of EmployeeForm (ActionForm), lets say
> "employeeForm"
> > 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> > 4. return mapping.findForward("editMode");
> >
> > I'm not sure whether this approach will work or not? And whether I
> have
> > to
> > make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode
> (
> > employeeFormEdit.jsp). If this the case, then I guess, I've to make
> > EmployeeFormEdit.java (ActionForm) as well.
> >
> > It will be great if anybody could help me here.
> >
> > Thanks in advance.
> >
> > Bye,
> > Viki.
> >
> >
>
>
> --
> Rick
>
>
Re: pre-populating form fields when called in edit mode.
Posted by Rick Reumann <ri...@gmail.com>.
I'm going to have a good lesson that will show exactly what you want, but
until then, if you want a quick preview of the Action class, put it here:
http://www.reumann.net/misc/EmployeeAction.txt
You are following an example where I showed using a separate Action for each
behaviour whereas the link above shows a DispatchAction. It's just a short
cut for putting related tasks in one action versus using separate actions.
Regardless, though, let's assume your separate Action approach which is just
fine.
I typically would make a SetUpAction that you would call "before" you
forwarded to the JSP page where you would be editing the form. So let's
assume you went to edit the Employee from a link you clicked on, the process
would be...
1) Click on link, passing something like an employeeID
2) link submits to your SetUpAction
3) In SetUpAction it checks the Request to see if an "employeeID" was passed
to it. If ti was, you go database get your Employee object (EmployeeDTO
following your old example) and then you can use BeanUtils like you did
before...
BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings you
to the "employeForm.jsp" page.
4) employeeForm is now all set up with the employee information and clicking
'submit' would bring you to an UpdateEmployeeAction to do the actual update
(just like you did for the InsertEmployeeAction).
You can easily reuse the form for doing both "inserts" and "updates."
Typically you'll have to do a little bti of logic for some of the verbage to
decide what to display (ie is header "Insert Employee" or "Update
Employee"). You can base your logic to decide what to display on various
things (in this case it could be as simple as looking for an "employeeID" ..
if you have one then you know you are doing an update... if you don't than
you are doing an insert, but of course there are plenty of other ways to do
it as well.
On 12/25/05, Vikrama Sanjeeva <vi...@gmail.com> wrote:
>
> Hi,
>
> Here is the sequence:
>
> 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> radio
> buttons, text area's and dropdowns.
> 2: On pressing "Submit" button in "employeeForm.jsp",
> "InsertEmployeeAction"
> is called which do the following:
>
> 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> 2.2) DataBaseService.insertEmployee (employeeDTO)
> 2.3) return mapping.findForward("success");
>
> Now, I want to call same "employeeForm.jsp" in "editable" mode, such that
> all the fields (text fields, radio buttons, text area's and dropdowns) are
> "pre-populated". What approaches are there to achieve this? I'm looking
> for
> a way which uses same BeanUtils.copyProperties() and copy the employeeDTO
> to employeeForm (Bean). Something like this:
>
> When user click's "Edit Employee Form" link, an action
> (EditEmployeeAction) will be called. Which will do the following:
>
> 1. Fetch the employee information from database in employeeDTO.
> 2. Get the "handle" of EmployeeForm (ActionForm), lets say "employeeForm"
> 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> 4. return mapping.findForward("editMode");
>
> I'm not sure whether this approach will work or not? And whether I have
> to
> make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode (
> employeeFormEdit.jsp). If this the case, then I guess, I've to make
> EmployeeFormEdit.java (ActionForm) as well.
>
> It will be great if anybody could help me here.
>
> Thanks in advance.
>
> Bye,
> Viki.
>
>
--
Rick