If you must use a redirect, however, you will have to do some extra work. You will not be able to use the <h:messages /> component by itself, because so far as I'm aware (and I don't have time to look at the javadocs or source code right now) it only will look for messages in request scope, so will miss anything you put in session scope. You will have to write some custom code to put the messages in the session, or in the FacesContext (which is itself stored in the session, of course), and to retrieve them from there. When you retrieve them, you will as you indicate have to also remove them, or they will persist.
I think using phase listeners would probably work to do what you want, but I'm not expert enough in JSF to be certain. You might be able to use one to extract any messages from the request and put them in the session, then another to retrieve them from the session (and remove them from the session at the same time), and put them into the new request that will have been created by the redirect, so the <h:messages /> tag can access them as normal.
You should only go that route if you're sure you really need to, though, IMHO. I think you might be much better served by using forwards, with tokens where necessary to protect against accidental resubmission.
-Matt
On 6/15/05, Richard Wallace <[EMAIL PROTECTED]> wrote:
Matt Blum wrote:
> The Faces servlet does a forward by default, so all you need to do is
> take out the redirect tag from your navigation rule, and that's what
> will happen.
>
Well, ok. But I guess I'm just not understanding where the code to put
the messages in the session would be in that case. Would it have to be
in the JSP page?
Rather than do something like that could I instead save the messages to
the session after the render response phase with a phase listener and
then restore them before the restore view phase with another?
This should work assuming that when a <h:messages /> element is
encountered it dequeues messages it displays, otherwise the messages
will just continually be added to the session and displayed over and
over again. As long as this is the case, I don't see a reason this
wouldn't work, what do you think?
Rich
> 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
> <http://people.apache.org/%7Ecraigmcc/shale-core-javadocs/org/apache/shale/component/Token.html>
>
I'm not worried about the user hitting the back button and resubmitting
the form. They'd have to actually want to go back to the form and
resubmit it. And that might be a perfectly valid use-case for some
people, using their browsers navigation rather than the site navigation.
>
> On 6/14/05, *Richard Wallace* <[EMAIL PROTECTED]
> <mailto: [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]>
> > <mailto:[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
> >
> >
>
>
