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 6 years, 10 months ago.

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

    Turkish Delight
    Participant

    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.

    #20477

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

    #20478

    Turkish Delight
    Participant

    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="#{book.name}">

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

    </h:link>

    The contents of the pretty-config:

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

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

    <view-id>/view.jsf</view-id>

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

    </url-mapping>

    The target view:

    <!-- ... -->

    <f:metadata>

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

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

    </f:metadata>

    <!-- ... -->

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

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

    </c:if>

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

    <!-- display book summary -->

    </c:if>

    The problem is that the c:if tests are being evaluated based on the last value of “empty bookSessionBean.book”, 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.

    #20479

    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 bookSessionBean.book}"> ... </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!

    –Lincoln

    #20480

    Turkish Delight
    Participant

    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: http://stackoverflow.com/questions/4348600/how-do-i-stop-el-expressions-from-being-evaluated-in-non-rendered-jsf-components ).

    #20481

    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)

You must be logged in to reply to this topic.

Comments are closed.