Awesome, thank you!
Greg Lindholm wrote:
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-validation-fails.html
Timothy Orme wrote:
Hi Greg,
Thanks, I actually just stumbled acros
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-validation-fails.html
Timothy Orme wrote:
>
> Hi Greg,
>
> Thanks, I actually just stumbled across this. I'm actually having some
> pr
Hi Greg,
Thanks, I actually just stumbled across this. I'm actually having some
problems with it however.
I have it setup as follows:
/form.jsp?id=${id}
/form.jsp?id=${id}
ViewData.action?id=${id}
To preserve your action errors and messages across a redirect you can use
this interceptor.
http://glindholm.wordpress.com/2008/07/02/preserving-messages-across-a-redirect-in-struts-2/
Timothy Orme wrote:
>
> Sorry to revive an old thread here, but I've run into another issue with
> this.
>
>
So this actually doesn't seem to work. Seems that I can't have the dispatcher result have an action as a parameter. Seems like it can only find a jsp even if I write out the full path to the action.
Does anyone have any other suggestions on this?
Thanks,
Tim Orme
Timothy Orme wrote:
Ok, I thin
Ok, I think this works. If I do:
ViewData.action?id=%{dataId}
ViewForm.action
And remove the redirect on "input", instead of
ViewData.action?id=%{dataId}
ViewForm.action
Then I think this will be ok. On the chance that the user does have a validation error,
Hi Timothy,
You may consider flow like this:
1. request from browser
2. action on server
3. result returned to browser
That way You can do as follows:
1. when receiving request for AddData
2. perform AddData action
3. then dispatch to apropriate forward
3.1. when with success redirect to ViewData
Sorry to revive an old thread here, but I've run into another issue with 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
Ok, this helps a lot. Simply from a usability standpoint though, the latter example seems more in line with what I'd want. It seems silly to have to bring the user to a page where, in my case, they
would invariably click a link. I was aware of the TokenSession interceptor, and as you stated, it do
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
I'm not really sure what you're suggesting here. Are you saying that I should put the dataId attribute in the session instead of passing it to the page? I'm not really sure what that helps, and in
fact it only seems to complicate the issue. Maybe I'm misunderstanding?
Thanks,
-Tim
Martin Gainty
Tim-
any reason why you would'nt put the attributes in Session by implementing
SessionAware
http://struts.apache.org/2.0.14/docs/how-do-we-get-access-to-the-session.html
put them in with setSession() and access with Map parameters=this.getSession()
http://struts.apache.org/2.0.14/struts2-core/
12 matches
Mail list logo
