FAQ
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

Search Discussions

  • Matt Blum at Jun 15, 2005 at 12:15 am
    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.
    On 6/14/05, Richard Wallace 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
  • Richard Wallace at Jun 15, 2005 at 2:34 am

    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* 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
  • Matt Blum at Jun 15, 2005 at 4:57 am
    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.

    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 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* <rwallace@thewallacepack.net
    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
  • Richard Wallace at Jun 15, 2005 at 2:30 pm

    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* 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* <rwallace@thewallacepack.net
    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
  • Matt Blum at Jun 15, 2005 at 3:47 pm
    If you do a forward, you don't need to put the messages in the session. A
    forward is entirely server-side, so there's only one request being
    processed. That's why a forward is by far the easiest way to deal with the
    issue.

    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 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* <rwallace@thewallacepack.net
    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* <rwallace@thewallacepack.net
    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
  • Richard Wallace at Jun 15, 2005 at 9:28 pm

    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* <rwallace@thewallacepack.net
    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* <rwallace@thewallacepack.net
    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
  • Korhonen, Kalle at Jun 15, 2005 at 2:36 am
    But, it's also so common use scenario that IMHO, the framework should
    support it. The only problem is how to differentiate that redirect
    request from other redirect scenarios. I could argue that the
    viewhandler or something below taking care of handling the navigation
    case should save the messages for the next request. Should we just open
    an enhancement issue for this in JIRA so we don't loose track of this?

    Mmm... I might need it myself at some point. Stupid real work gets in
    the way, I only wish I had more time to work on MyFaces :)

    Kalle


    ________________________________

    From: Matt Blum
    Sent: Tuesday, June 14, 2005 5:15 PM
    To: MyFaces Discussion
    Subject: Re: Messages and navigation rule redirects


    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.


    On 6/14/05, Richard Wallace 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedJun 14, '05 at 11:26p
activeJun 15, '05 at 9:28p
posts8
users3
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase