Evaluating query param in POST

Splash Forums PrettyFaces Users Evaluating query param in POST

This topic contains 18 replies, has 4 voices, and was last updated by  Christian Kaltepoth 10 years, 4 months ago.

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
  • #18022


    Hi all,

    I’m new in using pretty-faces. I’m currently working on a jsf remake of one app in a struts portal. I already created simple rewriting with params to giver a GET acces to three entry-points in my app, but now I try to access to my jsf app from another one.

    I use pretty-faces their to keep the old url working.

    So, the caller have a research form and post parameters to the jsf app. I try to catch the POST params and setting them in a managed bean then to execute a navigation method of my jsf research ctrl.

    Basically I ve :

    <url-mapping id="resarchExpress">

    <pattern value="/searchExpress.do" />

    <query-param name="nom">#{searchBean.lastname}</query-param>

    <query-param name="prenom">#{searchBean.firstname}</query-param>

    <query-param name="ou">#{searchBean.where}</query-param>



    searchBean is already used by searchCtrl inside my app (which has her own jsf entry point for a search). searchBean and searchCtrl are both managed bean in scope request.

    After posting data from outside, searchCtrl.searchExpress() is called but no value are passed to searchBean. I tryed to add a phaseId on my action (PROCESS_VALIDATIONS or RENDER_VIEW) but nothing change : the returned view is the common error view of an invalid search for lack of params.

    Whar am I missing ? Might be a very obvious or silly mistake, so don’t hesitate to correct me.

    Thanks in advance,



    On smartphone so this will be short. have you tried <h:form prependId="false"> on your search form?



    Yep, I got it on “false”. What’s the problem with this ?



    Sorry, I read it too fast. The first form is not in jsf, not in the same app, so there’s no prependId on the caller form.


    Ok. Have you taken a look at your POST request (Using something like HttpFox) to make sure that the parameters are actually what you think they are? What about when you send a GET request? Does that work?

    Which version of PrettyFaces are you using?



    The GET works, that’s the actual solution i’m working on (we already had a Post2Get filter for other uses, I tryied it on my url : bingo).

    So yes, the params are passed in the POST since it works properly with my filter. Is this a real solution or a workaround ?

    We use pretty-faces 3.2.0.



    add-on : Hmmm… pretty-faces 3.3.0 sorry.


    Hmm, the parameters should be evaluated in POST requests as well. It *should* be a real solution, I’m wondering what the problem is. Try setting:

    <query-param onPostback="true" ...> ... </...>



    As I’m in France, it will have to wait till monday. I had played with onPostback param first, but I might have missed something. Now that I know my rule works fine in GET, I will try again in POST. Thanks.


    @lincoln: Are you sure POST parameters are also captured by <query-param>? This would require HttpServletRequest.getParameter() to work for query parameters AND form post data! Is this really the case?


    I know that I used <query-param> to capture POST data in one of my previous implementations of SocialPM:

    pretty-config.xml (see backlog mapping)



    Ahh, maybe not. This may have enabled bookmarking, but it probably worked using the query-parameters, not necessarily the fact that it was a POST. You are probably right :(


    I just checked the API docs. It says:

    Request parameters are extra information sent with the request. For HTTP servlets, parameters are contained in the query string or posted form data.


    So it may work! But I never tried! :)



    Hi Lincoln, I had a quick look at the mechanism behind the “injection” of parameter values used by the QueryParam. The injectQueryParams method only look for parameters within the query string. I believe this was the problem.

    After modifying this method by adding an extra (second) level of parameter search from within the request object (used to store http post param) it allowed us to correctly evaluates the Prettyfaces post parameters.

    I did not require to use the onPostback attribute at all, but this involved a PrettyFaces code change.

    Could you tell me whether you are interested in this change? It is not a major change but quite a simple one in fact.

    @Christian, you were in the right track !

    Have a good day.


    Hey Yannv,

    thanks for looking into this issue.

    Sure! We are always interested in community contributions! Are you familiar with Git? In this case you could clone our repository and create a pull request. But you could also create a regular patch! In this case just create a ticket and attach the patch.

    Thank you! :)


Viewing 15 posts - 1 through 15 (of 19 total)

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

Comments are closed.