Return-Path: 
 <user-return-197220-apmail-struts-user-archive=struts.apache.org@struts.apache.org>
Delivered-To: apmail-struts-user-archive@www.apache.org
Received: (qmail 52991 invoked from network); 17 Mar 2009 20:24:18 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Mar 2009 20:24:18 -0000
Received: (qmail 58366 invoked by uid 500); 17 Mar 2009 20:24:08 -0000
Delivered-To: apmail-struts-user-archive@struts.apache.org
Received: (qmail 58340 invoked by uid 500); 17 Mar 2009 20:24:08 -0000
Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:user-unsubscribe@struts.apache.org>
List-Help: <mailto:user-help@struts.apache.org>
List-Post: <mailto:user@struts.apache.org>
List-Id: "Struts Users Mailing List" <user.struts.apache.org>
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Delivered-To: mailing list user@struts.apache.org
Received: (qmail 58329 invoked by uid 99); 17 Mar 2009 20:24:08 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2009 13:24:08 -0700
X-ASF-Spam-Status: No, hits=4.0 required=10.0
	tests=DNS_FROM_OPENWHOIS,FORGED_YAHOO_RCVD,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2009 20:23:58 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1Ljfp3-0005gc-9g
	for user@struts.apache.org; Tue, 17 Mar 2009 13:23:37 -0700
Message-ID: <22567093.post@talk.nabble.com>
Date: Tue, 17 Mar 2009 13:23:37 -0700 (PDT)
From: Greg Lindholm <glindholm@yahoo.com>
To: user@struts.apache.org
Subject: Re: Best Practices for Forms
In-Reply-To: <49C00550.700@genome.med.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Nabble-From: glindholm@yahoo.com
References: <49AC3462.8060806@genome.med.harvard.edu>
 <48692c2d0903021224x5803e45fhf1f7e30dadbb04d0@mail.gmail.com>
 <49AC487D.5000005@genome.med.harvard.edu>
 <49BFB808.6030606@genome.med.harvard.edu> <22566661.post@talk.nabble.com>
 <49C00550.700@genome.med.harvard.edu>
X-Virus-Checked: Checked by ClamAV on apache.org


Well that's about the most common question one sees on this list.
Check this out:

http://struts.apache.org/2.1.6/docs/how-do-we-repopulate-controls-when-vali=
dation-fails.html


Timothy Orme wrote:
>=20
> Hi Greg,
>=20
> =09Thanks, I actually just stumbled across this. I'm actually having some
> problems with it however.
>=20
> I have it setup as follows:
>=20
> <action name=3D"ViewForm" class=3D"ViewFormAction">
> =09<interceptor-ref name=3D"redirectStack" />=09=09=09
> =09<result name=3D"success">/form.jsp?id=3D${id}</result>
> =09<result name=3D"input">/form.jsp?id=3D${id}</result>
> </action>
>=20
> <action name=3D"AddData" class=3D"AddDataAction">
> =09<interceptor-ref name=3D"redirectStack" />=09=09
> =09<result name=3D"success" type=3D"redirect">ViewData.action?id=3D${id}<=
/result>
> =09<result name=3D"input" type=3D"redirect">ViewForm.action?id=3D${id}</r=
esult>
> </action>
>=20
> This comes close to working. If the user enters bad data, I get moved fro=
m
> the AddData action back to the ViewForm action, and the action errors are
> there, but now the dynamic parts of the form are=20
> not present. After debugging this, I see that when the user enters bad
> data, it hits the validate method of the AddData action, but never hits
> the execute() method of view form. What am I doing wrong?
>=20
> Thanks,
> Tim
>=20
> Greg Lindholm wrote:
>> To preserve your action errors and messages across a redirect you can us=
e
>> this interceptor.
>>=20
>> http://glindholm.wordpress.com/2008/07/02/preserving-messages-across-a-r=
edirect-in-struts-2/
>>=20
>>=20
>> Timothy Orme wrote:
>>> Sorry to revive an old thread here, but I've run into another issue wit=
h
>>> this.
>>>
>>> I decided to go with the second of Hernan's recommendations here, so I
>>> now
>>> have the following "flow".
>>>
>>> 1. User visits "ViewForm.action".
>>> 2. User submits the form and we go to "AddData.action"
>>> 3. If the data validated okay, we send the user on to "ViewData.action"=
,
>>> =09otherwise, we send them back to ViewForm.action.
>>>
>>> And in XML it looks something like:
>>>
>>> <action name=3D"AddData" class=3D"action.AddDataAction">
>>> =09<result name=3D"success"
>>> type=3D"redirect">ViewData.action?id=3D%{dataId}</result>
>>> =09<result name=3D"input" type=3D"redirect">ViewForm.action</result>
>>> </action>
>>>
>>> The problem is, as Hernan stated, that I now lose all my ActionErrors
>>> that
>>> were added to the stack. So the page redirects ok, but now if the user
>>> entered bad data, I can't send messages back to them=20
>>> to tell them what went wrong. Again, this seems like something that
>>> should
>>> be a common goal, but I can't seem to find the right way to do it. Does
>>> anyone have any suggestions?
>>>
>>> Thanks,
>>> Tim
>>>
>>> Timothy Orme wrote:
>>>> Ok, this helps a lot. Simply from a usability standpoint though, the=
=20
>>>> latter example seems more in line with what I'd want. It seems silly t=
o=20
>>>> have to bring the user to a page where, in my case, they would=20
>>>> invariably click a link. I was aware of the TokenSession interceptor,=
=20
>>>> and as you stated, it does fix the issue, but I was more curious about=
=20
>>>> the best practice.
>>>>
>>>> Thanks,
>>>> Tim
>>>>
>>>> hernan gonzalez wrote:
>>>>> To avoid the problem of duplicated submissions (not only when
>>>>> refreshing the result page, but also when double clicking the submit
>>>>> button, or going back to the submited form and submitting again) you
>>>>> should take a look at  the TokenSessionStoreInterceptor.
>>>>>
>>>>> But that is complementary with the other issue: it is not bad practic=
e
>>>>> to separate the actions "addData " from the action "viewData", the
>>>>> later is idempotent , the former is not. Hence, you might implement
>>>>> two separate Actions (or a same Action with two methods that return
>>>>> different results). For example
>>>>>
>>>>> ---------------------------------------------------------------------=
----------------=20
>>>>>
>>>>> <action name=3D"SubmitData" class=3D"action.SubmitDataAction">
>>>>>         <result name=3D"success">/viewSubmitResult.jsp</result>
>>>>> </action>
>>>>>
>>>>> <action name=3D"ViewData" class=3D"action.ViewDataAction">
>>>>>         <result name=3D"success">/viewData.jsp</result>
>>>>> </action>
>>>>>
>>>>> (Here SubmitDataAction should include the Token interceptor to avoid
>>>>> double submissions. And /viewSubmitResult.jsp might just show a
>>>>> generic succes message with a link to the ViewDataAction action)
>>>>>
>>>>> ---------------------------------------------------------------------=
---------------------------=20
>>>>>
>>>>>
>>>>> or
>>>>>
>>>>> <action name=3D"SubmitData" class=3D"action.SubmitDataAction">
>>>>>         <result name=3D"success"
>>>>> type=3D"redirect">ViewDataAction.do?id=3D%{dataId}</result>
>>>>> </action>
>>>>>
>>>>> <action name=3D"ViewData" class=3D"action.ViewDataAction">
>>>>>         <result name=3D"success">/viewData.jsp</result>
>>>>> </action>
>>>>>
>>>>> (This is a little more straightforward, but has the slight
>>>>> disadvantage of losing any ActionMessage you might have produced in
>>>>> the SubmitDataAction)
>>>>>
>>>>> ---------------------------------------------------------------------=
--------------------------------------------------=20
>>>>>
>>>>>
>>>>> Hern=C3=A1n J. Gonz=C3=A1lez
>>>>> http://hjg.com.ar/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>>
>>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>=20
>=20
>=20

--=20
View this message in context: http://www.nabble.com/Best-Practices-for-Form=
s-tp22295019p22567093.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org