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 11 years, 4 months ago.

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



    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?





    the mapping:

    <url-mapping id=”home” >

    <pattern value=”/home/” />


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


    <url-mapping id=”commandlinkgo” >

    <pattern value=”/secondPage” />


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



    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.



    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.


    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.



    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.



    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.


    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)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.