Re: Messages and navigation rule redirects

[Richard Wallace]

Richard Wallace 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?

Well you can forget that.  My assumption was incorrect, the messages are 
not dequeued by the <h:messages /> element.  Not only that, but when 
doing an add the render response phase for that page is never reached 
because it redirects to the other page instead.  Makes sense, but isn't 
too helpful in my situation =P.

Oh well, I'll have to figure out another way or just live with it the 
way it is.

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
    >
    >