struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jouravlev <>
Subject Re: help with a newbie topic-prepopulating a form
Date Wed, 06 Jul 2005 07:22:47 GMT
On 7/5/05, Rick Reumann <> wrote:
> Michael Jouravlev wrote the following on 7/6/2005 1:11 AM:
> > On 7/5/05, Rick Reumann <> wrote:
> >
> >>Use the reset method only for doing things like making sure some boolean
> >>fields are set to false. I highly recommend you DO NOT use the reset for
> >>'business type' logic. Having a few default things set there is fine,
> >>but for stuff like you are suggesting, you do that in an Action class or
> >>  DispatchAction method BEFORE you forward to the page.
> >
> >
> > Any particular reason for that? Also, if default values are set in
> > reset(), they will be overwritten by request values if there are any.
> Right. That's what you *want* to happen - otherwise what would be the
> point of reset if it never let the user's input overwrite the form's
> default values? Reset() is called first by struts *then* the form gets
> populated with any request parameters that match the form properties.

Right. This is why reset() is a good place for init values. If there
are no request values, init values will be used.

> > Usually, this is the preferred scenario. If values are set right
> > before rendering a page, then request values will be overwritten by
> > default values.
> NO this does not happen when you leave an Action and forward to a page.
> It only happens on "submit."

Are you saying that submit and render operations are served by
different actions? Original author did not imply that.

> Maybe you are confusing 'default' values
> that the form has with 'pre-poulated' values. A form that is used to
> edit user information, like the original poster mentioned he wanted, are
> 'pre-population' values - those you would never want to set in a reset
> (or even worse a validate) method.

I do not see any difference between default and pre-populated values.
These are values which are set in HTML form before a user gets chance
to change them. I do not care where these values come from: from a
property file or a database.

> Are you suggesting it's a good idea
> to call business logic (DAOs etc) in order to populate a form bean with
> information such as an "Employee name" or "Address"?  Hopefully it's
> just late and I'm misunderstaning you and you are not saying this:)

Why? What is the difference of calling DAO from action class or a form
bean? They are used in pair anyway.

> If by some chance you are, PLEASE do not advise the newbies to do this.
> This totally defeats the pupose of what ActionForms should be used for
> and will create all kinds of maintenance headaches, never mind the fact
> that it's really bad design.

Can you explain why is it so bad, besides that it is "bad design" and
"defeats pupose of what ActionForms should be used for"? What
ActionForms should be used for, anyway? It is just a class, which has
a simple lifecycle, maintained by Struts. Why the religious fear of
not doing something against how it "should be used for"? If it works,
why not?

> Typically for an "edit" scenario that the user mentioned, you'd click on
> a link with a userID, go to your Action, look up the UserObject from
> backend based on userID, populate your ActionForm with the user
> information, forward to the page to now alow the information to be
> edited and submitted.

I do almost the same, but because my form bean is used for output
only, that is, to prep the JSP, I can stick all code into form bean
and forgo action class altogether. Standard ForwardAction works well,
but I would prefer if I could return forward mapping right from the
form bean.

Now, this object is presented to a user, he makes changes, where the
request goes? To the same action or to a different one? If to the
same, then request values must not be overwritten by pre-populated
ones from database.  In your example they will be.

Whatever, I have a separate initialization event, which signals to the
component to pre-populate data. In other cases I use whatever is
currently retained in a form bean, which has session scope. Form bean
with session scope works like a simple object cache.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message