You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Erik Weber <er...@mindspring.com> on 2004/07/12 16:31:29 UTC
Prepopulating forms
Hello. I want to solicit some advice and opinions. Working on my first
Struts app.
I have some use cases that call for typcial "add" and "update"
functionality that basically can share the same forms. Obviously when
the form is first displayed under "add" conditions, it needs to be
blank. Under "update" conditions, the form needs to be prepopulated
using the results of a DB select. In addition, a few fields that are
present under "add" conditions no longer should be present under
"update" conditions.
My current plan is to:
1) Use two different JSPs to house these forms, even though there will
be a lot of redundancy, because the fields may have some variation, and
because I'm not fond of having conditionals in the form (if (add) { }
else { //must be update). I suppose the common block of fields could be
refactored into an include. Any opinions on this are welcome.
2) Prepopulate the "update" form by assigning an action to it. I suppose
the action would, in the execute method, call a business object, get a
value object and use the attributes of this object to set all the fields
of the ActionForm before returning a forward to the update form screen.
Is this the right approach? I would especially like opinions here. My
view screens have ".jsp" extensions but my screens that have submittable
forms have actions that use path mapping, such as "foo/login" and
"foo/register" and "foo/save", and so forth. Is it common to map
viewing/prepopulating actions one way and saving/writing actions another?
I have heard of the use of the "reset" method in an Action for
prepopulating a form, and indeed it looks convenient. I also have heard
Struts developers may want to deprecate this method.
Any advice/opinions/links welcome.
Thanks,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Parameterizing form JSPs with tags
Posted by Erik Weber <er...@mindspring.com>.
Rick Reumann wrote:
> On Mon, 12 Jul 2004 10:31:29 -0400, Erik Weber
> <er...@mindspring.com> wrote:
>
> (speaking of "add" form versus "update" form that are similar but not
> exactly the same . . ) I'd reuse the same form, even if it means
> some JSTL <c:choose><c:when test="${userAction == 'update'}>...</..>
> I find it ends up being easier in the long run.
I need a little help understanding how to do this.
I am parameterizing the handling of a few actions in a single action
class, and I decided to go with a single, shared form JSP, because it's
a big form. So I need to use a switch of some type to set the "action"
parameter of my html:form tag depending on the current usecase, and also
to conditionally render or omit a couple of fields of the form.
For example, if the action that led to the form page is
"/usecase/viewadd" then the user gets a blank form, and I need to set
the form action parameter to be "/usecase/add" If the action was
"/usecase/viewedit" instead, then the user gets a prepopulated form, and
I need to set the form action parameter to be "/usecase/save". You get
the idea. The part I need help with is building the JSP switch.
How does the JSP tag access the current "use case", or command
parameter? Do you have to manually set request attributes? What object
does "userAction" refer to in the above example?
Also, is there a Struts tag that will do the same thing? I don't have JSTL.
Thanks,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Sorry, you're right its not in this version - I've been living under that
misconception for weeks now.
Niall
----- Original Message -----
From: "Hubert Rabago" <ja...@yahoo.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, July 12, 2004 10:33 PM
Subject: Re: Prepopulating forms & validation
> I wanted to ask about this. The javadoc of Validator's Form.inherit field
(
>
http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/Form.html#inherit
> ) has it marked as "Since Validator 1.2.0", so I was thinking the
inheritance
> feature wasn't included yet. Do you know if this is the case?
>
> Hubert
>
> --- Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> > The version of commons validator (1.1.3 I think) that comes with the
> > recently released Sruts 1.2.1 beta allows you to inherit from another
form
> > definition using the extends attribute
> >
> > Niall
> >
> > ----- Original Message -----
> > From: "Erik Weber" <er...@mindspring.com>
> > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > Sent: Monday, July 12, 2004 10:09 PM
> > Subject: Re: Prepopulating forms & validation
> >
> >
> > > Thanks a lot! I no doubt will find that very useful.
> > >
> > > I have another question for the group at large:
> > >
> > > I am now using the same form successfully for adds and updates. I am
> > > using the Validator plugin for validation, which I find to be pretty
> > > awesome. The problem I face though is, the fields I need to validate
are
> > > slightly different between add and update conditions.
> > >
> > > For example, when I add, there is a "disclaimer" checkbox that *must*
be
> > > checked. When I update, there is no longer any checkbox. I am trying
to
> > > share the <form> element in validation.xml, obviously, because the
form
> > > itself is (almost) the same. So the problem is that sometimes I need
> > > "required", and sometimes not, for this checkbox field.
> > >
> > > Because of one or two fields being different between add and update
> > > forms, I fear I'll have to do a nearly-redundant (and very long)
<form>
> > > element for my update condition in validation.xml. Does anyone have a
> > > better solution?
> > >
> > > Thanks,
> > > Erik
> > >
> > >
> > >
> > > Rick Reumann wrote:
> > >
> > > > On Mon, 12 Jul 2004 12:22:11 -0400, Erik Weber
> > > > <er...@mindspring.com> wrote:
> > > >
> > > >> Using BeanUtils.copyProperties(), it's a piece of cake to update
> > > >> your Form bean from the ValueObject properties.
> > > >>
> > > >> Do you have an example of this, or is there one on your site? I
> > > >> indeed have some properties that are the same between form bean
and
> > > >> VO, but some are not (for example my form beans use only Strings,
> > > >> but my VOs use some booleans, ints, etc.)
> > > >
> > > >
> > > > Sorry was busy so unable to keep up with this thread.
> > > >
> > > > No, the types can all be different. BeanUtils will convert them for
> > > > you, so your formBean can have all Strings (some would argue it
> > > > should only be all Strings anyway) and your VO obviously will have
> > > > different types. To copy the properties from your VO to your form
> > > > bean it's as simple as:
> > > >
> > > > import org.apache.commons.beanutils.BeanUtils;
> > > >
> > > > BeanUtils.copyProperties(youFormBean, yourVO);
> > > >
> > > > If you are dealing with java.util.Dates you'll have one other thing
to
> > > > do (register a converter for your app) but I can explain that more
if
> > > > you need to go that route.
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Hubert Rabago <ja...@yahoo.com>.
I wanted to ask about this. The javadoc of Validator's Form.inherit field (
http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/Form.html#inherit
) has it marked as "Since Validator 1.2.0", so I was thinking the inheritance
feature wasn't included yet. Do you know if this is the case?
Hubert
--- Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> The version of commons validator (1.1.3 I think) that comes with the
> recently released Sruts 1.2.1 beta allows you to inherit from another form
> definition using the extends attribute
>
> Niall
>
> ----- Original Message -----
> From: "Erik Weber" <er...@mindspring.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Monday, July 12, 2004 10:09 PM
> Subject: Re: Prepopulating forms & validation
>
>
> > Thanks a lot! I no doubt will find that very useful.
> >
> > I have another question for the group at large:
> >
> > I am now using the same form successfully for adds and updates. I am
> > using the Validator plugin for validation, which I find to be pretty
> > awesome. The problem I face though is, the fields I need to validate are
> > slightly different between add and update conditions.
> >
> > For example, when I add, there is a "disclaimer" checkbox that *must* be
> > checked. When I update, there is no longer any checkbox. I am trying to
> > share the <form> element in validation.xml, obviously, because the form
> > itself is (almost) the same. So the problem is that sometimes I need
> > "required", and sometimes not, for this checkbox field.
> >
> > Because of one or two fields being different between add and update
> > forms, I fear I'll have to do a nearly-redundant (and very long) <form>
> > element for my update condition in validation.xml. Does anyone have a
> > better solution?
> >
> > Thanks,
> > Erik
> >
> >
> >
> > Rick Reumann wrote:
> >
> > > On Mon, 12 Jul 2004 12:22:11 -0400, Erik Weber
> > > <er...@mindspring.com> wrote:
> > >
> > >> Using BeanUtils.copyProperties(), it's a piece of cake to update
> > >> your Form bean from the ValueObject properties.
> > >>
> > >> Do you have an example of this, or is there one on your site? I
> > >> indeed have some properties that are the same between form bean and
> > >> VO, but some are not (for example my form beans use only Strings,
> > >> but my VOs use some booleans, ints, etc.)
> > >
> > >
> > > Sorry was busy so unable to keep up with this thread.
> > >
> > > No, the types can all be different. BeanUtils will convert them for
> > > you, so your formBean can have all Strings (some would argue it
> > > should only be all Strings anyway) and your VO obviously will have
> > > different types. To copy the properties from your VO to your form
> > > bean it's as simple as:
> > >
> > > import org.apache.commons.beanutils.BeanUtils;
> > >
> > > BeanUtils.copyProperties(youFormBean, yourVO);
> > >
> > > If you are dealing with java.util.Dates you'll have one other thing to
> > > do (register a converter for your app) but I can explain that more if
> > > you need to go that route.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
The version of commons validator (1.1.3 I think) that comes with the
recently released Sruts 1.2.1 beta allows you to inherit from another form
definition using the extends attribute
Niall
----- Original Message -----
From: "Erik Weber" <er...@mindspring.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, July 12, 2004 10:09 PM
Subject: Re: Prepopulating forms & validation
> Thanks a lot! I no doubt will find that very useful.
>
> I have another question for the group at large:
>
> I am now using the same form successfully for adds and updates. I am
> using the Validator plugin for validation, which I find to be pretty
> awesome. The problem I face though is, the fields I need to validate are
> slightly different between add and update conditions.
>
> For example, when I add, there is a "disclaimer" checkbox that *must* be
> checked. When I update, there is no longer any checkbox. I am trying to
> share the <form> element in validation.xml, obviously, because the form
> itself is (almost) the same. So the problem is that sometimes I need
> "required", and sometimes not, for this checkbox field.
>
> Because of one or two fields being different between add and update
> forms, I fear I'll have to do a nearly-redundant (and very long) <form>
> element for my update condition in validation.xml. Does anyone have a
> better solution?
>
> Thanks,
> Erik
>
>
>
> Rick Reumann wrote:
>
> > On Mon, 12 Jul 2004 12:22:11 -0400, Erik Weber
> > <er...@mindspring.com> wrote:
> >
> >> Using BeanUtils.copyProperties(), it's a piece of cake to update
> >> your Form bean from the ValueObject properties.
> >>
> >> Do you have an example of this, or is there one on your site? I
> >> indeed have some properties that are the same between form bean and
> >> VO, but some are not (for example my form beans use only Strings,
> >> but my VOs use some booleans, ints, etc.)
> >
> >
> > Sorry was busy so unable to keep up with this thread.
> >
> > No, the types can all be different. BeanUtils will convert them for
> > you, so your formBean can have all Strings (some would argue it
> > should only be all Strings anyway) and your VO obviously will have
> > different types. To copy the properties from your VO to your form
> > bean it's as simple as:
> >
> > import org.apache.commons.beanutils.BeanUtils;
> >
> > BeanUtils.copyProperties(youFormBean, yourVO);
> >
> > If you are dealing with java.util.Dates you'll have one other thing to
> > do (register a converter for your app) but I can explain that more if
> > you need to go that route.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Apologies Erik, its not in this version...maybe the next one.
Niall
----- Original Message -----
From: "Erik Weber" <er...@mindspring.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, July 12, 2004 10:44 PM
Subject: Re: Prepopulating forms & validation
> Awesome! Inheritance in, or parameterizing of, the Validator plugin,
> will be the last step in getting a CRU (no D) use case finished the
> *right* way (hopefully). This is with declarative validation,
> declarative exception handling, an action layer, a business layer and a
> data access layer (architect demanded these layers), as well as full use
> of Struts HTML tags for all forms, and some use of bean and logic tags,
> plus I wrote a PlugIn for combo box value arrays and a pluggable
> validator extension to do some "twofields" matching, and finally learned
> how to do conditional validation with requiredif. Oh, and of course the
> "static" content is all pulled from i18n-able properties files. Total
> time to learn Struts from scratch, set up JBoss, MySQL, CVS and get this
> use case working: Three weeks.
>
> Not too shabby eh? I'm sold on Struts, but the docs need to be revised,
> revised and revised some more! Maybe someday I'll have time to contribute.
>
> The only thing I have done redundantly is check for "loggedin-ness", but
> I will soon refactor that with a Servlet filter methinks.
>
> Thanks to all on this list who have helped! Can't wait till the clients
> ask for the site in Spanish!
>
> Erik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Erik Weber <er...@mindspring.com>.
Awesome! Inheritance in, or parameterizing of, the Validator plugin,
will be the last step in getting a CRU (no D) use case finished the
*right* way (hopefully). This is with declarative validation,
declarative exception handling, an action layer, a business layer and a
data access layer (architect demanded these layers), as well as full use
of Struts HTML tags for all forms, and some use of bean and logic tags,
plus I wrote a PlugIn for combo box value arrays and a pluggable
validator extension to do some "twofields" matching, and finally learned
how to do conditional validation with requiredif. Oh, and of course the
"static" content is all pulled from i18n-able properties files. Total
time to learn Struts from scratch, set up JBoss, MySQL, CVS and get this
use case working: Three weeks.
Not too shabby eh? I'm sold on Struts, but the docs need to be revised,
revised and revised some more! Maybe someday I'll have time to contribute.
The only thing I have done redundantly is check for "loggedin-ness", but
I will soon refactor that with a Servlet filter methinks.
Thanks to all on this list who have helped! Can't wait till the clients
ask for the site in Spanish!
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 17:09:41 -0400, Erik Weber <er...@mindspring.com>
wrote:
> I am now using the same form successfully for adds and updates. I am
> using the Validator plugin for validation, which I find to be pretty
> awesome. The problem I face though is, the fields I need to validate are
> slightly different between add and update conditions.
Use the ValidatorActionForm and validate on the Action name, not the form
name. Useful for just that reasons you've desscribed. You can have
different validation set up for the updateAction vs the insertAction.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 17:09:41 -0400, Erik Weber <er...@mindspring.com>
wrote:
> Because of one or two fields being different between add and update
> forms, I fear I'll have to do a nearly-redundant (and very long) <form>
> element for my update condition in validation.xml. Does anyone have a
> better solution?
Oh sorry I replied to soon. Yea this is a problem. I suggested a long time
ago that you should be able to 'extend' other validation xml definitions.
Not sure if that was ever worked on by anyone or not, but that would be
nice.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms & validation
Posted by Erik Weber <er...@mindspring.com>.
Thanks a lot! I no doubt will find that very useful.
I have another question for the group at large:
I am now using the same form successfully for adds and updates. I am
using the Validator plugin for validation, which I find to be pretty
awesome. The problem I face though is, the fields I need to validate are
slightly different between add and update conditions.
For example, when I add, there is a "disclaimer" checkbox that *must* be
checked. When I update, there is no longer any checkbox. I am trying to
share the <form> element in validation.xml, obviously, because the form
itself is (almost) the same. So the problem is that sometimes I need
"required", and sometimes not, for this checkbox field.
Because of one or two fields being different between add and update
forms, I fear I'll have to do a nearly-redundant (and very long) <form>
element for my update condition in validation.xml. Does anyone have a
better solution?
Thanks,
Erik
Rick Reumann wrote:
> On Mon, 12 Jul 2004 12:22:11 -0400, Erik Weber
> <er...@mindspring.com> wrote:
>
>> Using BeanUtils.copyProperties(), it's a piece of cake to update
>> your Form bean from the ValueObject properties.
>>
>> Do you have an example of this, or is there one on your site? I
>> indeed have some properties that are the same between form bean and
>> VO, but some are not (for example my form beans use only Strings,
>> but my VOs use some booleans, ints, etc.)
>
>
> Sorry was busy so unable to keep up with this thread.
>
> No, the types can all be different. BeanUtils will convert them for
> you, so your formBean can have all Strings (some would argue it
> should only be all Strings anyway) and your VO obviously will have
> different types. To copy the properties from your VO to your form
> bean it's as simple as:
>
> import org.apache.commons.beanutils.BeanUtils;
>
> BeanUtils.copyProperties(youFormBean, yourVO);
>
> If you are dealing with java.util.Dates you'll have one other thing to
> do (register a converter for your app) but I can explain that more if
> you need to go that route.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 12:22:11 -0400, Erik Weber <er...@mindspring.com>
wrote:
> Using BeanUtils.copyProperties(), it's a piece of cake to update your
> Form bean from the ValueObject properties.
>
> Do you have an example of this, or is there one on your site? I indeed
> have some properties that are the same between form bean and VO, but
> some are not (for example my form beans use only Strings, but my VOs use
> some booleans, ints, etc.)
Sorry was busy so unable to keep up with this thread.
No, the types can all be different. BeanUtils will convert them for you,
so your formBean can have all Strings (some would argue it should only be
all Strings anyway) and your VO obviously will have different types. To
copy the properties from your VO to your form bean it's as simple as:
import org.apache.commons.beanutils.BeanUtils;
BeanUtils.copyProperties(youFormBean, yourVO);
If you are dealing with java.util.Dates you'll have one other thing to do
(register a converter for your app) but I can explain that more if you
need to go that route.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Erik Weber <er...@mindspring.com>.
Thanks Rick. As I said in another response, I think I will go with a
shared add/update form.
Also, I think we meant the same thing, as far as action mappings go, I
just didn't explain very clearly. Indeed, I think now I will just map an
action to every screen and the user will never see "*.jsp" at the end of
a URI, but rather things like "/viewdetails" or what have you.
You wrote:
Using BeanUtils.copyProperties(), it's a piece of cake to update your
Form bean from the ValueObject properties.
Do you have an example of this, or is there one on your site? I indeed
have some properties that are the same between form bean and VO, but
some are not (for example my form beans use only Strings, but my VOs use
some booleans, ints, etc.)
Thanks for your help,
Erik
Rick Reumann wrote:
> On Mon, 12 Jul 2004 10:31:29 -0400, Erik Weber
> <er...@mindspring.com> wrote:
>
>> 1) Use two different JSPs to house these forms, even though there
>> will be a lot of redundancy, because the fields may have some
>> variation, and because I'm not fond of having conditionals in the
>> form (if (add) { } else { //must be update). I suppose the common
>> block of fields could be refactored into an include. Any opinions on
>> this are welcome.
>
>
> It depends on 'how' different the forms will be. If they are the same
> except for a few fields, I'd reuse the same form, even if it means
> some JSTL <c:choose><c:when test="${userAction == 'update'}>...</..>
> I find it ends up being easier in the long run. Too many time some
> manager will come to me and say, we need to move the columns around,
> or this item should be above this item. I like to edit this all in
> one place, vs two. That being said, if the forms are mostly different
> except for a few fields, then seperate forms may work out better.
>
>>
>> 2) Prepopulate the "update" form by assigning an action to it. I
>> suppose the action would, in the execute method, call a business
>> object, get a value object and use the attributes of this object to
>> set all the fields of the ActionForm before returning a forward to
>> the update form screen. Is this the right approach?
>
>
> I think so. Using BeanUtils.copyProperties(), it's a piece of cake to
> update your Form bean from the ValueObject properties.
>
>> I would especially like opinions here. My view screens have ".jsp"
>> extensions but my screens that have submittable forms have actions
>> that use path mapping, such as "foo/login" and "foo/register" and
>> "foo/save", and so forth. Is it common to map viewing/prepopulating
>> actions one way and saving/writing actions another?
>
>
> I'm an unclear what you mean be the above. All my pages are jsp pages
> with .jsp extension but the user never ever will see that in the URL
> since everything I do forwards through an action. Even just views
> should forward through an action even if it's just the simple generic
> ForwardAction.
>
>> I have heard of the use of the "reset" method in an Action for
>> prepopulating a form, and indeed it looks convenient.
>
>
> It should never pre-populate it with business data, but it's ok to use
> it for making sure certain values are reset to defaults... such as
> checkboxes, radio buttons, etc. You really need to make use of the
> reset method if you have checkboxes on your form and you are using
> validation or the form has session scope. Just don't think of
> pre-populating meaning prepopulating from your backend - that stuff
> should be done in your Action. I usually use some form of
> DispatchAction and usually always have a SetUp() method that does all
> my population from the ValueObject(s).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 10:31:29 -0400, Erik Weber <er...@mindspring.com>
wrote:
> 1) Use two different JSPs to house these forms, even though there will
> be a lot of redundancy, because the fields may have some variation, and
> because I'm not fond of having conditionals in the form (if (add) { }
> else { //must be update). I suppose the common block of fields could be
> refactored into an include. Any opinions on this are welcome.
It depends on 'how' different the forms will be. If they are the same
except for a few fields, I'd reuse the same form, even if it means some
JSTL <c:choose><c:when test="${userAction == 'update'}>...</..>
I find it ends up being easier in the long run. Too many time some manager
will come to me and say, we need to move the columns around, or this item
should be above this item. I like to edit this all in one place, vs two.
That being said, if the forms are mostly different except for a few
fields, then seperate forms may work out better.
>
> 2) Prepopulate the "update" form by assigning an action to it. I suppose
> the action would, in the execute method, call a business object, get a
> value object and use the attributes of this object to set all the fields
> of the ActionForm before returning a forward to the update form screen.
> Is this the right approach?
I think so. Using BeanUtils.copyProperties(), it's a piece of cake to
update your Form bean from the ValueObject properties.
> I would especially like opinions here. My view screens have ".jsp"
> extensions but my screens that have submittable forms have actions that
> use path mapping, such as "foo/login" and "foo/register" and "foo/save",
> and so forth. Is it common to map viewing/prepopulating actions one way
> and saving/writing actions another?
I'm an unclear what you mean be the above. All my pages are jsp pages with
.jsp extension but the user never ever will see that in the URL since
everything I do forwards through an action. Even just views should forward
through an action even if it's just the simple generic ForwardAction.
> I have heard of the use of the "reset" method in an Action for
> prepopulating a form, and indeed it looks convenient.
It should never pre-populate it with business data, but it's ok to use it
for making sure certain values are reset to defaults... such as
checkboxes, radio buttons, etc. You really need to make use of the reset
method if you have checkboxes on your form and you are using validation or
the form has session scope. Just don't think of pre-populating meaning
prepopulating from your backend - that stuff should be done in your
Action. I usually use some form of DispatchAction and usually always have
a SetUp() method that does all my population from the ValueObject(s).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Erik Weber <er...@mindspring.com>.
Joe and Wendy, thanks for all your help. Hearing the practical advice
and the theoretical advice gives me a plan for getting things done but
also keeps me thinking toward the best way of doing things!
I think what you are saying here will dawn on me more as I get deeper
into development, and I have a feeling I'll need to revisit the caveats
you have highlighted here. So I appreciate it.
Have a great day!
Erik
Joe Germuska wrote:
> At 12:16 PM -0400 7/12/04, Erik Weber wrote:
>
>> Joe, thanks for your opinion. You and Rick have convinced me to stay
>> with one form page for add/update. I did this before in a non-struts
>> app, and despite all the conditionals I ended up with, the ensuing
>> layout revisions did make it worth it.
>>
>> So, Joe, I am not using Dyna Forms, just plain old form beans. (I may
>> refactor my DTOs/VOs and form beans into some base class because of
>> all the shared fields, but for now, I'm getting a lot of use out of a
>> bean generator I wrote). Are you agreeing then, that the best
>> approach (currently) is to create an action for the view screen (in
>> this case, the "update" form page), and in that action, obtain a VO
>> and use the values from that to set the properties of the ActionForm?
>> You are saying if I do this I need to explicity set a key to the form
>> as a request attribute? (Somehow I assumed that the form already
>> would be set as an attribute and that all I would need to do is
>> modify the values of it).
>
>
> When Struts calls execute(mapping ,form,request,response), the form
> that it passes in is determined by the "name" attribute of the
> ActionMapping. The name, of course, must reference a <form-bean>
> element, which determines the type.
>
> The ActionForm specified in the ActionMapping is intended as the
> wrapper for request parameters, so only in limited cases will it also
> be of the correct type for the subsequent view. If the only request
> parameter your action needs is the ID of the VO object you'll retrieve
> for population, then you could probably get away with specifying the
> "view form" (or "output form") in the ActionMapping. It's just
> important to note that this isn't how Struts is designed, and that
> inevitably, you'll come upon a case where you need to pass in more
> input data and therefore really need distinct form-beans for "input"
> and "output".
>
> I believe in letting consenting adults do what they please, and so if
> you understand this, I think you can do it safely. Some people are
> kind of purists and insist on having a form bean even for the single
> ID parameter which might be coming in to your action.
>
> Getting back to specifics, Struts uses the "name" and "scope"
> properties of an action-mapping to pass form beans between the
> controller and the view. If your pre-view action and your
> form-submission action have the same values then everything should
> work out (with a possible exception if you are using "request" scope
> and use a redirect, which would cause the "controller request" to go
> out-of-scope before the view can be drawn using that data.
>
> In the case when you can't use the same form-bean in your action and
> in the subsequent view and yet you want to pre-populate a form in your
> view, you simply must ensure that a form-bean of the proper type is
> placed in the proper scope under the proper name by your action (or by
> a Tiles controller, or by any other logic that can sneak in before the
> view is rendered).
>
> Hope that helps!
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Joe Germuska <Jo...@Germuska.com>.
At 12:16 PM -0400 7/12/04, Erik Weber wrote:
>Joe, thanks for your opinion. You and Rick have convinced me to stay
>with one form page for add/update. I did this before in a non-struts
>app, and despite all the conditionals I ended up with, the ensuing
>layout revisions did make it worth it.
>
>So, Joe, I am not using Dyna Forms, just plain old form beans. (I
>may refactor my DTOs/VOs and form beans into some base class because
>of all the shared fields, but for now, I'm getting a lot of use out
>of a bean generator I wrote). Are you agreeing then, that the best
>approach (currently) is to create an action for the view screen (in
>this case, the "update" form page), and in that action, obtain a VO
>and use the values from that to set the properties of the
>ActionForm? You are saying if I do this I need to explicity set a
>key to the form as a request attribute? (Somehow I assumed that the
>form already would be set as an attribute and that all I would need
>to do is modify the values of it).
When Struts calls execute(mapping ,form,request,response), the form
that it passes in is determined by the "name" attribute of the
ActionMapping. The name, of course, must reference a <form-bean>
element, which determines the type.
The ActionForm specified in the ActionMapping is intended as the
wrapper for request parameters, so only in limited cases will it also
be of the correct type for the subsequent view. If the only request
parameter your action needs is the ID of the VO object you'll
retrieve for population, then you could probably get away with
specifying the "view form" (or "output form") in the ActionMapping.
It's just important to note that this isn't how Struts is designed,
and that inevitably, you'll come upon a case where you need to pass
in more input data and therefore really need distinct form-beans for
"input" and "output".
I believe in letting consenting adults do what they please, and so if
you understand this, I think you can do it safely. Some people are
kind of purists and insist on having a form bean even for the single
ID parameter which might be coming in to your action.
Getting back to specifics, Struts uses the "name" and "scope"
properties of an action-mapping to pass form beans between the
controller and the view. If your pre-view action and your
form-submission action have the same values then everything should
work out (with a possible exception if you are using "request" scope
and use a redirect, which would cause the "controller request" to go
out-of-scope before the view can be drawn using that data.
In the case when you can't use the same form-bean in your action and
in the subsequent view and yet you want to pre-populate a form in
your view, you simply must ensure that a form-bean of the proper type
is placed in the proper scope under the proper name by your action
(or by a Tiles controller, or by any other logic that can sneak in
before the view is rendered).
Hope that helps!
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Erik Weber" <er...@mindspring.com>
> Joe, thanks for your opinion. You and Rick have convinced me to stay
> with one form page for add/update. I did this before in a non-struts
> app, and despite all the conditionals I ended up with, the ensuing
> layout revisions did make it worth it.
Take a look at LookupDispatchAction. That's what I use to control which
CRUD action is happening, and all the code stays in one Action class.
Instead of separate 'add' and 'update' Actions, they would be methods within
your EditWhateverAction.
Dynamic forms or not doesn't really matter... you just use the 'form' object
that gets passed into your method. And since it's a reference to the form
that's sitting in request or session scope, you don't have to "put" it
anywhere, it's already there.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: R: Prepopulating forms
Posted by Joe Germuska <Jo...@Germuska.com>.
At 6:33 PM +0200 7/12/04, Amleto Di Salle wrote:
>Hi all,
>you can use the action in order to obtain the VO.
>
>But a question: Are you using the html tags inside your jsp?
>If yes, you can put the VO in the request and use the "value" (for
>example value="${requestScope.anObject.aProperty}") attribute in the
>html tags (for example "html:text).
>I would like to appreciate some comments in order to use this solution.
This works, in a sense, but then overrides the ability of the html:*
tags to re-present user-entered data in the case of server-side
validation errors.
It's generally considered better for usability if you present exactly
the data the user entered when returning them to a form page because
of validation errors. This is also why it's generally advised to
make your free-text-entry form bean properties of type String even if
you want the user to enter a number.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: R: Prepopulating forms
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 13:02:21 -0400, Erik Weber <er...@mindspring.com>
wrote:
> I recall that when I set the "value" property on any of my inputs, I ran
> into a problem with user input changes being "remembered" in the case of
> a page reload due to form validation failure.
This depends Erik. If you are harcoding it like:
<html:text property="dogName" value="Spot"/> //!NOT GOOD
<html:text property="dogName" value="${yourForm.dogName}"/> //ok, but silly
The later should be ok, but would be a waste since the html tag will take
care of setting the value for you when you use 'property.'
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: R: Prepopulating forms
Posted by Erik Weber <er...@mindspring.com>.
Yes, I am using the html tags. I thought of what you are saying, but if
I understand the responses of others correctly (particularly Wendy),
just calling the setters of your form in your "prepopulate" action
should take care of this; you shouldn't have to explicity provide any
values to your html tags. At least in simplistic/typical situations this
seemingly would work. (In other words, the Struts html tags are going to
prepopulate for you). I think also though Joe's comments about possibly
needing different form beans for input/output should be considered.
I recall that when I set the "value" property on any of my inputs, I ran
into a problem with user input changes being "remembered" in the case of
a page reload due to form validation failure.
Someone correct me if I am wrong please.
Erik
Amleto Di Salle wrote:
>Hi all,
>you can use the action in order to obtain the VO.
>
>But a question: Are you using the html tags inside your jsp?
>If yes, you can put the VO in the request and use the "value" (for
>example value="${requestScope.anObject.aProperty}") attribute in the
>html tags (for example "html:text).
>I would like to appreciate some comments in order to use this solution.
>
>BR
>/Amleto
>
>
>
>-----Messaggio originale-----
>Da: Erik Weber [mailto:erikweber@mindspring.com]
>Inviato: lunedì 12 luglio 2004 18.17
>A: Struts Users Mailing List
>Oggetto: Re: Prepopulating forms
>
>
>Joe, thanks for your opinion. You and Rick have convinced me to stay
>with one form page for add/update. I did this before in a non-struts
>app, and despite all the conditionals I ended up with, the ensuing
>layout revisions did make it worth it.
>
>So, Joe, I am not using Dyna Forms, just plain old form beans. (I may
>refactor my DTOs/VOs and form beans into some base class because of all
>the shared fields, but for now, I'm getting a lot of use out of a bean
>generator I wrote). Are you agreeing then, that the best approach
>(currently) is to create an action for the view screen (in this case,
>the "update" form page), and in that action, obtain a VO and use the
>values from that to set the properties of the ActionForm? You are saying
>
>if I do this I need to explicity set a key to the form as a request
>attribute? (Somehow I assumed that the form already would be set as an
>attribute and that all I would need to do is modify the values of it).
>
>Thanks again,
>Erik
>
>
>
>Joe Germuska wrote:
>
>
>
>>In my experience, it helps all involved to avoid redundancy and
>>copying. If you logically treat inserts and updates as more "same"
>>than "different" then you're better off making one page with
>>conditionals. This serves as implicit documentation of the fact that
>>they are more the same, while having two JSPs suggests that they are
>>more different. Someone who doesn't know the details (including you in
>>
>>
>
>
>
>>the future after your next project crowds out the details of this one)
>>
>>
>
>
>
>>will understand better if you only duplicate things when there is a
>>good reason for it. In my personal taste and experience, avoiding
>>conditional logic blocks in a form isn't a good reason for it.
>>
>>As for performing the pre-population, this is somewhat cumbersome. If
>>you are not using a session-scoped form, then it is somewhat tricky to
>>
>>
>
>
>
>>get a handle on the "output form" which needs populating. The Struts
>>"execute" signature passes in an "input form" based on request
>>parameters. Even if you were using session scoped forms, this assumes
>>that you want to use the same form bean for input and output, which is
>>
>>
>
>
>
>>often not the case.
>>
>>If your form bean is a simple non-dynamic form, then it's not too big
>>a deal to instantiate the bean, populate it, and put it in request or
>>session scope under the "name" attribute associated with the action
>>which receives the form submission. This is the bare minimum to do to
>>"make it work." If you're using DynaForms, it's a little harder to get
>>
>>
>
>
>
>>an instance.
>>
>>In the Struts 1.3 timeline, I'm hoping to work on some things to make
>>this easier. If you are interested in the details and in being on the
>>"bleeding edge," feel free to subscribe to the dev@struts list where
>>this would be discussed/critiqued/etc. I can't use the pending release
>>
>>
>
>
>
>>of 1.2.1 as an excuse any more, so now I just have to squeeze time
>>into my schedule to get started.
>>
>>Joe
>>
>>At 10:31 AM -0400 7/12/04, Erik Weber wrote:
>>
>>
>>
>>>Hello. I want to solicit some advice and opinions. Working on my
>>>first Struts app.
>>>
>>>I have some use cases that call for typcial "add" and "update"
>>>functionality that basically can share the same forms. Obviously when
>>>
>>>
>
>
>
>>>the form is first displayed under "add" conditions, it needs to be
>>>blank. Under "update" conditions, the form needs to be prepopulated
>>>using the results of a DB select. In addition, a few fields that are
>>>present under "add" conditions no longer should be present under
>>>"update" conditions.
>>>
>>>My current plan is to:
>>>
>>>1) Use two different JSPs to house these forms, even though there
>>>will be a lot of redundancy, because the fields may have some
>>>variation, and because I'm not fond of having conditionals in the
>>>form (if (add) { } else { //must be update). I suppose the common
>>>block of fields could be refactored into an include. Any opinions on
>>>this are welcome.
>>>
>>>2) Prepopulate the "update" form by assigning an action to it. I
>>>suppose the action would, in the execute method, call a business
>>>object, get a value object and use the attributes of this object to
>>>set all the fields of the ActionForm before returning a forward to
>>>the update form screen. Is this the right approach? I would
>>>especially like opinions here. My view screens have ".jsp" extensions
>>>
>>>
>
>
>
>>>but my screens that have submittable forms have actions that use path
>>>
>>>
>
>
>
>>>mapping, such as "foo/login" and "foo/register" and "foo/save", and
>>>so forth. Is it common to map viewing/prepopulating actions one way
>>>and saving/writing actions another?
>>>
>>>I have heard of the use of the "reset" method in an Action for
>>>prepopulating a form, and indeed it looks convenient. I also have
>>>heard Struts developers may want to deprecate this method.
>>>
>>>Any advice/opinions/links welcome.
>>>
>>>Thanks,
>>>
>>>Erik
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Amleto Di Salle" <di...@di.univaq.it>
> But a question: Are you using the html tags inside your jsp?
> If yes, you can put the VO in the request and use the "value" (for
> example value="${requestScope.anObject.aProperty}") attribute in the
> html tags (for example "html:text).
If you do that, you'll have a problem if you need to re-display the users
input if it fails validation. With a 'value' attribute, that's always what
will get displayed, not the value in the form bean.
Pre-population belongs in the Action code, then Struts can properly handle
what to display in the HTML form.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
R: Prepopulating forms
Posted by Amleto Di Salle <di...@di.univaq.it>.
Hi all,
you can use the action in order to obtain the VO.
But a question: Are you using the html tags inside your jsp?
If yes, you can put the VO in the request and use the "value" (for
example value="${requestScope.anObject.aProperty}") attribute in the
html tags (for example "html:text).
I would like to appreciate some comments in order to use this solution.
BR
/Amleto
-----Messaggio originale-----
Da: Erik Weber [mailto:erikweber@mindspring.com]
Inviato: lunedì 12 luglio 2004 18.17
A: Struts Users Mailing List
Oggetto: Re: Prepopulating forms
Joe, thanks for your opinion. You and Rick have convinced me to stay
with one form page for add/update. I did this before in a non-struts
app, and despite all the conditionals I ended up with, the ensuing
layout revisions did make it worth it.
So, Joe, I am not using Dyna Forms, just plain old form beans. (I may
refactor my DTOs/VOs and form beans into some base class because of all
the shared fields, but for now, I'm getting a lot of use out of a bean
generator I wrote). Are you agreeing then, that the best approach
(currently) is to create an action for the view screen (in this case,
the "update" form page), and in that action, obtain a VO and use the
values from that to set the properties of the ActionForm? You are saying
if I do this I need to explicity set a key to the form as a request
attribute? (Somehow I assumed that the form already would be set as an
attribute and that all I would need to do is modify the values of it).
Thanks again,
Erik
Joe Germuska wrote:
> In my experience, it helps all involved to avoid redundancy and
> copying. If you logically treat inserts and updates as more "same"
> than "different" then you're better off making one page with
> conditionals. This serves as implicit documentation of the fact that
> they are more the same, while having two JSPs suggests that they are
> more different. Someone who doesn't know the details (including you in
> the future after your next project crowds out the details of this one)
> will understand better if you only duplicate things when there is a
> good reason for it. In my personal taste and experience, avoiding
> conditional logic blocks in a form isn't a good reason for it.
>
> As for performing the pre-population, this is somewhat cumbersome. If
> you are not using a session-scoped form, then it is somewhat tricky to
> get a handle on the "output form" which needs populating. The Struts
> "execute" signature passes in an "input form" based on request
> parameters. Even if you were using session scoped forms, this assumes
> that you want to use the same form bean for input and output, which is
> often not the case.
>
> If your form bean is a simple non-dynamic form, then it's not too big
> a deal to instantiate the bean, populate it, and put it in request or
> session scope under the "name" attribute associated with the action
> which receives the form submission. This is the bare minimum to do to
> "make it work." If you're using DynaForms, it's a little harder to get
> an instance.
>
> In the Struts 1.3 timeline, I'm hoping to work on some things to make
> this easier. If you are interested in the details and in being on the
> "bleeding edge," feel free to subscribe to the dev@struts list where
> this would be discussed/critiqued/etc. I can't use the pending release
> of 1.2.1 as an excuse any more, so now I just have to squeeze time
> into my schedule to get started.
>
> Joe
>
> At 10:31 AM -0400 7/12/04, Erik Weber wrote:
>
>> Hello. I want to solicit some advice and opinions. Working on my
>> first Struts app.
>>
>> I have some use cases that call for typcial "add" and "update"
>> functionality that basically can share the same forms. Obviously when
>> the form is first displayed under "add" conditions, it needs to be
>> blank. Under "update" conditions, the form needs to be prepopulated
>> using the results of a DB select. In addition, a few fields that are
>> present under "add" conditions no longer should be present under
>> "update" conditions.
>>
>> My current plan is to:
>>
>> 1) Use two different JSPs to house these forms, even though there
>> will be a lot of redundancy, because the fields may have some
>> variation, and because I'm not fond of having conditionals in the
>> form (if (add) { } else { //must be update). I suppose the common
>> block of fields could be refactored into an include. Any opinions on
>> this are welcome.
>>
>> 2) Prepopulate the "update" form by assigning an action to it. I
>> suppose the action would, in the execute method, call a business
>> object, get a value object and use the attributes of this object to
>> set all the fields of the ActionForm before returning a forward to
>> the update form screen. Is this the right approach? I would
>> especially like opinions here. My view screens have ".jsp" extensions
>> but my screens that have submittable forms have actions that use path
>> mapping, such as "foo/login" and "foo/register" and "foo/save", and
>> so forth. Is it common to map viewing/prepopulating actions one way
>> and saving/writing actions another?
>>
>> I have heard of the use of the "reset" method in an Action for
>> prepopulating a form, and indeed it looks convenient. I also have
>> heard Struts developers may want to deprecate this method.
>>
>> Any advice/opinions/links welcome.
>>
>> Thanks,
>>
>> Erik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Erik Weber <er...@mindspring.com>.
Joe, thanks for your opinion. You and Rick have convinced me to stay
with one form page for add/update. I did this before in a non-struts
app, and despite all the conditionals I ended up with, the ensuing
layout revisions did make it worth it.
So, Joe, I am not using Dyna Forms, just plain old form beans. (I may
refactor my DTOs/VOs and form beans into some base class because of all
the shared fields, but for now, I'm getting a lot of use out of a bean
generator I wrote). Are you agreeing then, that the best approach
(currently) is to create an action for the view screen (in this case,
the "update" form page), and in that action, obtain a VO and use the
values from that to set the properties of the ActionForm? You are saying
if I do this I need to explicity set a key to the form as a request
attribute? (Somehow I assumed that the form already would be set as an
attribute and that all I would need to do is modify the values of it).
Thanks again,
Erik
Joe Germuska wrote:
> In my experience, it helps all involved to avoid redundancy and
> copying. If you logically treat inserts and updates as more "same"
> than "different" then you're better off making one page with
> conditionals. This serves as implicit documentation of the fact that
> they are more the same, while having two JSPs suggests that they are
> more different. Someone who doesn't know the details (including you in
> the future after your next project crowds out the details of this one)
> will understand better if you only duplicate things when there is a
> good reason for it. In my personal taste and experience, avoiding
> conditional logic blocks in a form isn't a good reason for it.
>
> As for performing the pre-population, this is somewhat cumbersome. If
> you are not using a session-scoped form, then it is somewhat tricky to
> get a handle on the "output form" which needs populating. The Struts
> "execute" signature passes in an "input form" based on request
> parameters. Even if you were using session scoped forms, this assumes
> that you want to use the same form bean for input and output, which is
> often not the case.
>
> If your form bean is a simple non-dynamic form, then it's not too big
> a deal to instantiate the bean, populate it, and put it in request or
> session scope under the "name" attribute associated with the action
> which receives the form submission. This is the bare minimum to do to
> "make it work." If you're using DynaForms, it's a little harder to get
> an instance.
>
> In the Struts 1.3 timeline, I'm hoping to work on some things to make
> this easier. If you are interested in the details and in being on the
> "bleeding edge," feel free to subscribe to the dev@struts list where
> this would be discussed/critiqued/etc. I can't use the pending release
> of 1.2.1 as an excuse any more, so now I just have to squeeze time
> into my schedule to get started.
>
> Joe
>
> At 10:31 AM -0400 7/12/04, Erik Weber wrote:
>
>> Hello. I want to solicit some advice and opinions. Working on my
>> first Struts app.
>>
>> I have some use cases that call for typcial "add" and "update"
>> functionality that basically can share the same forms. Obviously when
>> the form is first displayed under "add" conditions, it needs to be
>> blank. Under "update" conditions, the form needs to be prepopulated
>> using the results of a DB select. In addition, a few fields that are
>> present under "add" conditions no longer should be present under
>> "update" conditions.
>>
>> My current plan is to:
>>
>> 1) Use two different JSPs to house these forms, even though there
>> will be a lot of redundancy, because the fields may have some
>> variation, and because I'm not fond of having conditionals in the
>> form (if (add) { } else { //must be update). I suppose the common
>> block of fields could be refactored into an include. Any opinions on
>> this are welcome.
>>
>> 2) Prepopulate the "update" form by assigning an action to it. I
>> suppose the action would, in the execute method, call a business
>> object, get a value object and use the attributes of this object to
>> set all the fields of the ActionForm before returning a forward to
>> the update form screen. Is this the right approach? I would
>> especially like opinions here. My view screens have ".jsp" extensions
>> but my screens that have submittable forms have actions that use path
>> mapping, such as "foo/login" and "foo/register" and "foo/save", and
>> so forth. Is it common to map viewing/prepopulating actions one way
>> and saving/writing actions another?
>>
>> I have heard of the use of the "reset" method in an Action for
>> prepopulating a form, and indeed it looks convenient. I also have
>> heard Struts developers may want to deprecate this method.
>>
>> Any advice/opinions/links welcome.
>>
>> Thanks,
>>
>> Erik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Joe Germuska <Jo...@Germuska.com>.
Yes, I think that's a great improvement. Still, I feel like Struts
should be responsible for managing the scopes and the placement of
the form bean into the correct scope.
Also, and this may just be because I got on the "view controller"
horse a long time ago, but I feel like there should be a config file
that knows the name and scope of the form bean, and it should be
hooked to the forward config, and not hard-coded into the action.
Am I just being too much of a formalist?
Joe
At 10:09 PM +0100 7/12/04, Niall Pemberton wrote:
>Do you not think that the new standard mechanism in Struts 1.2.1 for
>creating ActionForms (regular or Dyna) makes this more straight forward?
>
>public ActionForward execute(ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response) throws Excetpion {
>
> // Find the FormBeanConfig
> FormBeanConfig config =
>mapping.getModuleConfig().findFormBeanConfig("myForm");
>
> // Create new ActionForm
> ActionForm newForm = config.createActionForm(servlet);
>
>}
>
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Rick Reumann <st...@reumann.net>.
On Mon, 12 Jul 2004 22:09:15 +0100, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
>
> // Find the FormBeanConfig
> FormBeanConfig config =
> mapping.getModuleConfig().findFormBeanConfig("myForm");
I've only rarely ever had to create Forms in my Actions (like you're doing
in the above). I'd be curious about cases when you would ever need to do
this? The only time that I see having to do this is when you plan to
actually nest ActionForms within ActionForms (and thus have to build some
in order to nest them), which in that case I wouldn't even bother nesting
ActionForms and would just use the VO and nest that. Validation has to be
done more manually, but no big deal.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Joe,
Do you not think that the new standard mechanism in Struts 1.2.1 for
creating ActionForms (regular or Dyna) makes this more straight forward?
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Excetpion {
// Find the FormBeanConfig
FormBeanConfig config =
mapping.getModuleConfig().findFormBeanConfig("myForm");
// Create new ActionForm
ActionForm newForm = config.createActionForm(servlet);
}
Niall
----- Original Message -----
Joe Germuska wrote ......
> If your form bean is a simple non-dynamic form, then it's not too big
> a deal to instantiate the bean, populate it, and put it in request or
> session scope under the "name" attribute associated with the action
> which receives the form submission. This is the bare minimum to do
> to "make it work." If you're using DynaForms, it's a little harder
> to get an instance.
>
> In the Struts 1.3 timeline, I'm hoping to work on some things to make
> this easier. If you are interested in the details and in being on
> the "bleeding edge," feel free to subscribe to the dev@struts list
> where this would be discussed/critiqued/etc. I can't use the pending
> release of 1.2.1 as an excuse any more, so now I just have to squeeze
> time into my schedule to get started.
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Prepopulating forms
Posted by Joe Germuska <Jo...@Germuska.com>.
In my experience, it helps all involved to avoid redundancy and
copying. If you logically treat inserts and updates as more "same"
than "different" then you're better off making one page with
conditionals. This serves as implicit documentation of the fact that
they are more the same, while having two JSPs suggests that they are
more different. Someone who doesn't know the details (including you
in the future after your next project crowds out the details of this
one) will understand better if you only duplicate things when there
is a good reason for it. In my personal taste and experience,
avoiding conditional logic blocks in a form isn't a good reason for
it.
As for performing the pre-population, this is somewhat cumbersome.
If you are not using a session-scoped form, then it is somewhat
tricky to get a handle on the "output form" which needs populating.
The Struts "execute" signature passes in an "input form" based on
request parameters. Even if you were using session scoped forms,
this assumes that you want to use the same form bean for input and
output, which is often not the case.
If your form bean is a simple non-dynamic form, then it's not too big
a deal to instantiate the bean, populate it, and put it in request or
session scope under the "name" attribute associated with the action
which receives the form submission. This is the bare minimum to do
to "make it work." If you're using DynaForms, it's a little harder
to get an instance.
In the Struts 1.3 timeline, I'm hoping to work on some things to make
this easier. If you are interested in the details and in being on
the "bleeding edge," feel free to subscribe to the dev@struts list
where this would be discussed/critiqued/etc. I can't use the pending
release of 1.2.1 as an excuse any more, so now I just have to squeeze
time into my schedule to get started.
Joe
At 10:31 AM -0400 7/12/04, Erik Weber wrote:
>Hello. I want to solicit some advice and opinions. Working on my
>first Struts app.
>
>I have some use cases that call for typcial "add" and "update"
>functionality that basically can share the same forms. Obviously
>when the form is first displayed under "add" conditions, it needs to
>be blank. Under "update" conditions, the form needs to be
>prepopulated using the results of a DB select. In addition, a few
>fields that are present under "add" conditions no longer should be
>present under "update" conditions.
>
>My current plan is to:
>
>1) Use two different JSPs to house these forms, even though there
>will be a lot of redundancy, because the fields may have some
>variation, and because I'm not fond of having conditionals in the
>form (if (add) { } else { //must be update). I suppose the common
>block of fields could be refactored into an include. Any opinions on
>this are welcome.
>
>2) Prepopulate the "update" form by assigning an action to it. I
>suppose the action would, in the execute method, call a business
>object, get a value object and use the attributes of this object to
>set all the fields of the ActionForm before returning a forward to
>the update form screen. Is this the right approach? I would
>especially like opinions here. My view screens have ".jsp"
>extensions but my screens that have submittable forms have actions
>that use path mapping, such as "foo/login" and "foo/register" and
>"foo/save", and so forth. Is it common to map viewing/prepopulating
>actions one way and saving/writing actions another?
>
>I have heard of the use of the "reset" method in an Action for
>prepopulating a form, and indeed it looks convenient. I also have
>heard Struts developers may want to deprecate this method.
>
>Any advice/opinions/links welcome.
>
>Thanks,
>
>Erik
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org