View object not expiring for h:link with f:param when PrettyFaces enabled

Splash Forums PrettyFaces Users View object not expiring for h:link with f:param when PrettyFaces enabled

This topic contains 5 replies, has 3 voices, and was last updated by  Christian Kaltepoth 11 years, 1 month ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #17835

    Turkish Delight

    I have an h:link with an f:param to redirect to a view that has a PrettyFaces rewrite applied to it (switching view.jsf?id=12345 to /view/12345). When PrettyFaces is disabled, it works as expected. But when PrettyFaces is enabled, it looks like the view isn’t being rebuilt: the JSTL c:if tag builds the wrong components *until* the page is reloaded, then it works correctly. Is this a known bug? Is there some trick to force PrettyFaces to re-build the view? Thanks for a terrific product!

    PrettyFaces 3.1.0, GlassFish Open Source Edition 3.0.1 (22), Mojarra 2.0.2 (FCS b10)

    Also PrimeFaces 2.2 RC2 and Tomahawk 1.1.10 if they could interefere.


    Could you please post the relevant parts of your configuration? Especially the pretty-config.xml and the h:link you are using?


    Turkish Delight

    I doubt it has to do with the h:link, because this still happens if I just enter the URLs into the address bar, regardless if I use the pretty /view/12345 syntax or the standard /view.jsf?id=12345 syntax. Here it is anyway:

    <h:link outcome="view" value="#{}">

    <f:param name="id" value="#{}" />


    The contents of the pretty-config:

    <url-mapping id="public-view-book">

    <pattern value="/view/#{ id }" />


    <query-param name="id">#{id}</query-param>


    The target view:

    <!-- ... -->


    <f:viewParam name="id" value="#{bookSessionBean.bookId}" />

    <f:event type="preRenderView" listener="#{bookSessionBean.loadBookByIdForPublic}" />


    <!-- ... -->

    <c:if test="#{empty}">

    <!-- "book not found" -->


    <c:if test="#{not empty}">

    <!-- display book summary -->


    The problem is that the c:if tests are being evaluated based on the last value of “empty”, not based on the current one. I.e., if I go to /view/123invalid_id, then navigate to /view/12345, I still get the “book not found” block built instead of the summary for book #12345. If I reload the page, then I get the summary for #12345. If I then go to /view/67890, I get the summary for book #67890 right away (because the same component tree is used), but if I then go back to /view/123invalid_id without then reloading, it tries to display the summary for a non-existent book, causing a NullPointerException instead of displaying the “book not found” block.


    My first suggestion is going to be to avoid c:if whenever possible – they are compile time checks, not runtime checks.

    I recommend using:

    <h:panelGroup rendered="#{empty}"> ... </h:panelGroup>

    c:if will give you lots of problems in JSF2, including with AJAX, tables, and loops.

    I may embarrass myself later with this statement, but I’m surprised that prettyfaces would change any behavior here. In fact, I’d go so far as to say that it actually cannot unless something is very wrong that I don’t know about. So I think the problem is not related to prettyfaces (strange though that you said it only occurs with prettyfaces enabled)

    Hope this helps!



    Turkish Delight

    Thanks, Lincoln! I know that using rendered=”…” attributes is generally preferable to c:if, and it does prevent this problem, but using c:if was a solution to a different problem I had been having (I’ll post it to StackOverflow for good measure: ).


    I totally agree to Lincoln’s suggestion. Don’t use <c:if> in your applications and instead use the rendered attribute. I cannot imagine a single case where <c:if> should be preferred. Actually I never used it in any of my application. The NPE you are seeing is probably related to something else.

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

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

Comments are closed.