You can fix the reload issue with a token, which is a server-generated value stored submitted with the form that's checked on submission and invalidated, so that if the form is re-submitted, the server will detect it. This would allow you to, if the form is resubmitted, redirect the user to an error page or somesuch (or do anything else you wanted to do). This is something you should do anyway, because even if you do a redirect the user could always use the browser's back button and resubmit the form.
Craig McClanahan has included an excellent JSF-friendly implementation of this in Shale. See the javadocs here:
http://people.apache.org/~craigmcc/shale-core-javadocs/org/apache/shale/component/Token.html
HTH.
-Matt
On 6/14/05, Richard Wallace <[EMAIL PROTECTED]> wrote:
Matt Blum wrote:
> This has been asked a number of times on this mailing list.
>
> The messages are stored in the request object, so you're losing them
> with the redirect. You should probably use a forward, unless there's
> a truly compelling reason to use a redirect. If you must use a
> redirect (say, so users can bookmark the resulting page), you'll have
> to first forward to something that will extract the messages from the
> request and put them in the session, and then do the redirect you were
> trying to do in the first place.
>
> -Matt.
The main purpose is to avoid the user being able to hit the browsers
reload button and having the form submitted a second time and a
duplicate entry being created in the database. How would I use a
forward? I'm not exactly sure how to do that. Is that in the
navigation rule or somewhere else? Will that accomplish what I need?
Thanks,
Rich
>
> On 6/14/05, *Richard Wallace* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >> wrote:
>
> Hello again,
>
> This should be a pretty simple problem. In the CRUD app that I'm
> using
> as a proof-of-concept for using JSF here at work I've got everything
> working and think I'm starting to understand some of the nuances of
> JSF. But one thing that is not working as I expected is the
> handling of
> messages.
>
> When a user creates an object (say a contact), after filling out the
> form and hitting submit they are redirected to the contact list
> page via
> the navigational rule:
>
> <navigation-rule>
> <from-view-id>/contact/add.jsp</from-view-id>
> <navigation-case>
> <from-action>#{contactHandler.saveContact }</from-action>
> <from-outcome>success</from-outcome>
> <to-view-id>/contact/list.jsp</to-view-id>
> <redirect/>
> </navigation-case>
> </navigation-rule>
>
> That works and all, but in the contactHandler.saveContact() method
> I am
> also adding an informational message that the contact was saved
> just to
> give the user a warm fuzzy feeling. So, in my list.jsp page I
> have the
> <h:view> followed immediately by <h:messages />. But nothing is
> displayed when the user is redirected to this page after successfully
> adding a contact. I know I'm adding it right because I'm doing it
> the
> same way on the /contact/edit.jsp page which doesn't redirect after a
> successful edit.
>
> The only things I can think of that would cause this is that JSF is
> processing the /contact/add.jsp page before doing the redirect, and
> there is a <h:messages /> tag in there in case there is some
> validation
> error or some other problem. But that's just a guess.
>
> The other possibility to me is that the messages are somehow page
> specific, so a message generated on one page won't show up on
> another.
> In which case my question is how do I get around this?
>
> Could it maybe have something to do with the backing bean that
> generates
> the message being request scoped rather than session scoped?
>
> Once again, thanks for the help
> Rich
>
>
