query-param decode="false"

Splash Forums PrettyFaces Users query-param decode="false"

This topic contains 7 replies, has 2 voices, and was last updated by  Lincoln Baxter III 6 years, 8 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #17786

    Plblm
    Participant

    Hi,

    I’m using the following mappings to pass ‘param1’ from pageA to pageB.

    The parameters are passed ok.

    The result URL is ‘/secondPage?param1=value1’

    I want the result URL to be ‘/secondpage’ (without the ?param1=value1)

    I am using decode=”false” as you can see.

    Any thoughts?

    Maybe url rewriting?

    Regards,

    Plato

    #20210

    Plblm
    Participant

    the mapping:

    <url-mapping id=”home” >

    <pattern value=”/home/” />

    <view-id>/faces/pagea.xhtml</view-id>

    <query-param name=”param1″ decode=”false” > #{bean.param1} </query-param>

    </url-mapping>

    <url-mapping id=”commandlinkgo” >

    <pattern value=”/secondPage” />

    <view-id>/faces/pageb.xhtml</view-id>

    <query-param name=”param1″ decode=”false” > #{bean.param1} </query-param>

    </url-mapping>

    #20211

    It depends on how you are navigating; if using prettyfaces navigation “pretty:”, then you need to make sure that the value of #{bean.param1} is null before you invoke navigation.

    #20212

    Plblm
    Participant

    Thanks for replying!

    Yes I am navigating by returning “pretty:commandlinkgo” (the id of the second mapping).

    But I’m retrieving the value in the second page (pageB.xhtml).

    If I make it null, like this

    param1 = null;

    return “pretty:commandlinkgo”;

    I’ll get null in the second page.

    #20213

    It sounds like you want to navigate to pageB without the query-parameter, but still have the value in the bean?

    I think that version 3.1.0 or 3.1.1 includes support for the query-parameter onPostback attribute:

    <query-param name=”param1″ onPostback=”false”> which should prevent that parameter from being injected again on navigation, but I don’t think there’s a way to exclude it.

    Hmm… maybe a new enhancement request coming for this.

    What is the problem with having the value in the URL? That’s really safer since it ensures bookmark-ability.

    Without the query-parameter in the URL, your bean must be Session or Conversation scoped, and that’s not going to be bookmarkable.

    #20214

    Plblm
    Participant

    I’m using some javascript code in pageA,

    that stores some data to a hidden field.

    Then after some user action I navigate to

    pageB where I store the data from the previous page

    in an other hidden field,

    in order for some other javascript code to pick up the data.

    (Switching between GWT modules).

    No the beans are RequestScopped I handle the state

    in the GWT module on the client.

    #20215

    Plblm
    Participant

    By the way before using PrettyFaces,

    I was able to pass the param1 between the two pages

    by using a <managed-property> param1 on faces-config.xml

    and h:commandLink and f:param on pageA.

    But after I included PrettyFaces the above mechanism stopped working.

    #20216

    There’s an important difference between using h:commmandLink, and using PrettyFaces navigation.

    PrettyFaces navigation issues an HTTP-redirect, which means that an entirely separate request-response are issued to/from the browser. This means that all of your request scoped beans will no longer have values, and also means that the parameter value from the prior form POSTBACK (form submission) will no longer be available once that separate request is issued. This is called the “postback-redirect-pattern.”

    Here’s a flow of how this works:

    JSF Navigation:

    Page A requested --> Page A rendered
    Page A submitted via commandLink --> jsf navigation invoked --> Page B rendered

    PrettyFaces Navigation:

    Page A requested --> Page A rendered
    Page A submitted via commandLink --> prettyfaces navigation invoked --> redirect to page B issued to browser
    //at this point, any values submitted in the form need to have been handled, or they will be lost
    Page B requested --> Page B rendered

    The reason <managed-property> worked before is because there was no redirect after the POST, your action method invoked standard JSF navigation which in turn performed an internal rendering of the new view without issuing a browser-redirect to the URL of the new page.

    You should not attempt to combine PrettyFaces mappings with the faces-config.xml file managed parameters or navigation, since they function in fundamentally different ways. PrettyFaces is intended to move managed-parameters into the URL so that they do not need to be configured in JSF, and can be bookmarked by web-users.

    I’m not sure if this was a clear explanation, but let me know if that makes more sense.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

Comments are closed.