FAQ
Hello!

I have a jsp page which is reached by using a commandLink with a
parameter. In the page I have a form with validation. If validation
fails, and the user is redirected back to the page, the parameter is
lost. Is this expected behavior? Is there a way around this?

/Olof

Search Discussions

  • Adrian Mitev at Jan 8, 2007 at 7:19 pm
    It is expected because the request parameter is in request scope.

    2007/1/8, Olof Næssén <olof.naessen@gmail.com>:
    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?

    /Olof
  • Simon Kitching at Jan 8, 2007 at 7:53 pm

    Olof Næssén wrote:
    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?
    Hmm..you have page A which has a commandLink that encodes a URL for page
    B with a parameter?

    Why would you use an f:param tag rather than using t:updateActionListener?

    Anyway, in page B, obviously no validation is going to occur on first
    access, because this is not a "postback" to page B; this is simply a
    "first render" of the page. The special parameter value *will* be
    accessable at this point.

    Are you somehow then expecting this parameter to continue to exist as
    page B is submitted? It won't be. Instead, just copy it into the
    "backing bean" for page B on the first render...

    Regards,

    Simon
  • Harlan Iverson at Jan 8, 2007 at 9:54 pm
    it may not be feasable in your situation, but I have used the tomahawk
    sandbox form tag for a situation like this (taking a restful URL and using
    the value on a request scoped bean). it allows you to specify an action
    attribute, which works like a normal html form. unfortunately you also have
    to use tomahawk commandLink and possibly other tomahawk components.
    On 1/8/07, Simon Kitching wrote:

    Olof Næssén wrote:
    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?
    Hmm..you have page A which has a commandLink that encodes a URL for page
    B with a parameter?

    Why would you use an f:param tag rather than using t:updateActionListener?

    Anyway, in page B, obviously no validation is going to occur on first
    access, because this is not a "postback" to page B; this is simply a
    "first render" of the page. The special parameter value *will* be
    accessable at this point.

    Are you somehow then expecting this parameter to continue to exist as
    page B is submitted? It won't be. Instead, just copy it into the
    "backing bean" for page B on the first render...

    Regards,

    Simon
  • Olof Næssén at Jan 9, 2007 at 11:37 am
    Why would you use an f:param tag rather than using t:updateActionListener?
    I didn't know updateActionListener existed. And frankly I don't really
    see the difference. Before I used a f:param embedded in a
    h:commandLink, now I use a t:updateActionListener embedded in a
    h:commandLink but I get the same result. Perhaps I'm missing
    something.
    Are you somehow then expecting this parameter to continue to exist as
    page B is submitted?
    Well I somehow thought the "state" of the previous page would be
    restored on validation failure. Maybe I should explain what I'm trying
    to do. I have an entry which a user can add comments to, much like a
    blog entry with user comments. When a user displays the entry a form
    for comment submission is present.

    To be able to display the entry I pass an entry id. The form I have
    has a hidden component with the entry id used when saving the comment,
    _but_ when validation fails the entry id is null despite the fact that
    I use a hidden component. My guess is that it's set to null because
    there is no parameter longer present (in my managed beans section I
    set the id property with the parameter, perhaps this is wrong), which
    would imply that parameters properties are set after post data
    properties.
    it may not be feasable in your situation, but I have used the tomahawk
    sandbox form tag for a situation like this
    Maybe the tomahawk sanbox form is a solution, but to me it seems like
    this is a quite common thing to do and I strongly suspect, as stated
    before, that I'm missing something obvious.

    /Olof
    On 1/8/07, Harlan Iverson wrote:
    it may not be feasable in your situation, but I have used the tomahawk
    sandbox form tag for a situation like this (taking a restful URL and using
    the value on a request scoped bean). it allows you to specify an action
    attribute, which works like a normal html form. unfortunately you also have
    to use tomahawk commandLink and possibly other tomahawk components.


    On 1/8/07, Simon Kitching wrote:
    Olof Næssén wrote:
    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?
    Hmm..you have page A which has a commandLink that encodes a URL for page
    B with a parameter?

    Why would you use an f:param tag rather than using t:updateActionListener?

    Anyway, in page B, obviously no validation is going to occur on first
    access, because this is not a "postback" to page B; this is simply a
    "first render" of the page. The special parameter value *will* be
    accessable at this point.

    Are you somehow then expecting this parameter to continue to exist as
    page B is submitted? It won't be. Instead, just copy it into the
    "backing bean" for page B on the first render...

    Regards,

    Simon
  • Simon Kitching at Jan 9, 2007 at 8:26 pm

    Olof Næssén wrote:
    Why would you use an f:param tag rather than using
    t:updateActionListener?
    I didn't know updateActionListener existed. And frankly I don't really
    see the difference. Before I used a f:param embedded in a
    h:commandLink, now I use a t:updateActionListener embedded in a
    h:commandLink but I get the same result. Perhaps I'm missing
    something.
    t:updateActionListener and f:param are totally different.

    t:updateActionListener will update a value in the specified MODEL object
    when the associated command is invoked by the user. In other words, it's
    properly integrated with JSF.

    f:param simply messes about with the http request parameters, leaving
    the JSF code to somehow look for the data and deal with it. It's a
    servlet-level (not JSF) operation, which makes it useful for generating
    URLs that are to be handled by non-JSF code.
    Are you somehow then expecting this parameter to continue to exist as
    page B is submitted?
    Well I somehow thought the "state" of the previous page would be
    restored on validation failure. Maybe I should explain what I'm trying
    to do. I have an entry which a user can add comments to, much like a
    blog entry with user comments. When a user displays the entry a form
    for comment submission is present.

    To be able to display the entry I pass an entry id. The form I have
    has a hidden component with the entry id used when saving the comment,
    _but_ when validation fails the entry id is null despite the fact that
    I use a hidden component. My guess is that it's set to null because
    there is no parameter longer present (in my managed beans section I
    set the id property with the parameter, perhaps this is wrong), which
    would imply that parameters properties are set after post data
    properties.
    I think that t:updateActionListener would be perfect for this situation.

    Or perhaps t:saveState so that the managed bean that holds info about
    the "currently displayed entry" has a lifetime longer than request-scope.

    Using the jsf standard session scope to hold the "currently displayed
    entry" for the user should also work, but session-scope has a number of
    problems; the tomahawk t:saveState approach is generally better.


    If you'll forgive me for saying so, it looks like you are trying to
    build a JSF application using a struts or plain servlets approach. Try
    thinking more like a Swing programmer; JSF is about components, not
    about knowing specifically what html parameters are being posted by the
    browser. It does take some adjustment...

    Regards,

    Simon
  • Brindamour, Michael at Jan 26, 2007 at 4:01 pm
    Hello,

    I am trying to find the jar files for the myfaces sandbox... they don't
    appear on the myfaces download page... can anyone help out?

    Thanks!
    Mike

    --
    Michael Brindamour
    NetSight Engineering, Enterasys Networks, Inc.
    Office: (978) 684-1332
    Fax: (call above before faxing) (978) 684-1691
    Cell: (603) 682-0014
    Email: mbrindam@enterasys.com
  • Gerald Müllan at Jan 26, 2007 at 4:12 pm
    Hi,

    have a look at our nightly builds section:

    http://people.apache.org/builds/myfaces/nightly/

    Sandbox will never be officially released, therefore no announcements
    and no download link on the main page.

    cheers,

    Gerald
    On 1/26/07, Brindamour, Michael wrote:


    Hello,

    I am trying to find the jar files for the myfaces sandbox... they don't
    appear on the myfaces download page... can anyone help out?

    Thanks!
    Mike

    --
    Michael Brindamour
    NetSight Engineering, Enterasys Networks, Inc.
    Office: (978) 684-1332
    Fax: (call above before faxing) (978) 684-1691
    Cell: (603) 682-0014
    Email: mbrindam@enterasys.com

    --
    http://www.irian.at

    Your JSF powerhouse -
    JSF Consulting, Development and
    Courses in English and German

    Professional Support for Apache MyFaces
  • Roman Rezac at Jan 11, 2007 at 10:20 am

    Olof Næssén <olof.naessen <at> gmail.com> writes:


    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?

    /Olof

    Hi there.
    I am facing the same issue. Did you find a solution for this? Thanks in advance.
  • Olof Næssén at Jan 11, 2007 at 3:05 pm
    I solved it by using t:updateActionListener to pass the id to the
    backing bean when the user selected to view the entry and by using
    t:saveState in the entry to save the id if validation failed.
    t:updateActionListener and f:param are totally different.
    Yes I can see that now, thanks for clearing it out for me. But as
    said, I had to use t:saveState as the action listener of the form
    isn't called (as far as I know) when validation fails.

    Thanks everyone for helping me, especially you Simon!

    /Olof
    On 1/11/07, Roman Rezac wrote:
    Olof Næssén <olof.naessen <at> gmail.com> writes:
    Hello!

    I have a jsp page which is reached by using a commandLink with a
    parameter. In the page I have a form with validation. If validation
    fails, and the user is redirected back to the page, the parameter is
    lost. Is this expected behavior? Is there a way around this?

    /Olof

    Hi there.
    I am facing the same issue. Did you find a solution for this? Thanks in advance.


Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedJan 8, '07 at 11:31a
activeJan 26, '07 at 4:12p
posts10
users7
websitemyfaces.apache.org

People

Translate

site design / logo © 2018 Grokbase