Late injection with postback query

Splash Forums PrettyFaces Users Late injection with postback query

This topic contains 22 replies, has 3 voices, and was last updated by  Christian Kaltepoth 6 years, 3 months ago.

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • #17957

    Zhomart
    Participant

    Hi guys,

    I’ve faced following problem:

    Simple page has parameter injection into bean from URL. On normal GET queries, everything seems to be working fine. On POST queries generated from <h:form>, actual injection of the parameter is happening at RESTORE_VIEW phase, but after c:if’s “test”, c:forEach’s “items” and ui:repeat’s “value” attributes are being evaluated at the same phase RESTORE_VIEW…

    So, I am getting into troubles every time c:if, c:forEach depend on the URL mapped value and the page is containing form.

    I saw somewhere on the site that injection must be done right before RESTORE_VIEW phase, is it a bug? Or I am doing something wrong?

    Some logs generated by app:

    RESTORE_VIEW 1 – getList(): <– invoked by <c:forEach items=”#{temp.list}”>

    RESTORE_VIEW 1 – setToTouch(12) <– invoked by pretty-faces <pattern value=”/temp/#{ toTouch : temp.toTouch }” />

    Thx beforehand.

    #21011

    Zhomart
    Participant

    In case guys I was not very clear, here is the sample:

    temp.xhtml:

    <h:form>

    <h:inputText value=”#{temp.p1}” />

    <c:if test=”#{not empty temp.toTouch}”>

    <h:inputText value=”#{temp.p2}” />

    </c:if>

    <h:commandButton value=”submit” />

    </h:form>

    pretty-config.xml:

    <url-mapping id=”temp”>

    <pattern value=”/temp/#{ toTouch : temp.toTouch }” />

    <view-id>/faces/page/temp.xhtml</view-id>

    </url-mapping>

    Whatever you enter in both input’s, value of the first one would be preserved only, since second one is not in restored tree…

    #21012

    Zhomart
    Participant

    History:

    RESTORE_VIEW 1 – getToTouch():

    RESTORE_VIEW 1 – setToTouch(12)

    RENDER_RESPONSE 6 – getToTouch(): 12

    RENDER_RESPONSE 6 – getToTouch(): 12

    RENDER_RESPONSE 6 – getToTouch(): 12

    #21013

    Zhomart
    Participant

    Just downloaded PrettyFaces 3.2.1 from http://ocpsoft.com/prettyfaces/

    Also tried to download latest 2.1, but nothing changed, only the number of invocations of getToTouch reduced…

    #21014

    I just looked into the source. You are right. The injection is done AFTER and not BEFORE RESTORE_VIEW. There is a comment in the source saying:

    Parameter validation and injection must occur after RESTORE_VIEW in order to participate in faces-navigation.

    Is there any reason you are using things like c:forEach and c:if? It is not very common to use these because they are evaluated during the construction of the component tree. Why don’t you use things like the rendered attribute of standard JSF components instead?

    See this blog post for some details on the differences:

    http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets

    #21015

    Zhomart
    Participant

    Ok, I can get rid of c:if, it’s not a big issue, it’s just a matter of convenience with c:choose.

    But there is no workable substitution for c:forEach as I know, by workable, I mean that would work in my case with pretty faces as it supposed to.

    ui:repeat would evaluate value=”” attribute before pretty faces would do injection, so it’s as with c:if….

    I am quite surprised, nobody had the same problem? Because, it’s always there if you use collection and form in the same page, where collection somehow depends on URL mapped value.

    Can you suggest any work-around’s about it, please?

    #21016

    Zhomart
    Participant

    I don’t get that comment…

    “after RESTORE_VIEW in order to participate in faces-navigation.”

    How injected variables could affect participation in navigation? Is it a bug?

    #21017

    Zhomart
    Participant

    Issue could be solved only using tr:trinidad from the user side =)

    #21018

    Zhomart
    Participant

    sorry, <tr:iterator, using trinidad.

    #21019

    You could also use ‘<ui:repeat>’, no? That is built into facelets and is the preferred iteration strategy for jsf.

    #21020

    I just had a thought though. Prettyfaces could actually execute the methods before RESTORE view, cache the return value until after restore view, then perform navigation.

    #21021

    Zhomart
    Participant

    ui:repeat somehow invokes getter before pretty as well as c:if.

    Really? How to execute methods before RESTORE view ? I mean on the request-scoped backings that would be clean on postback query.

    #21022

    I guess Lincoln meant that we could change this behavior in the PrettyFaces code.

    Another option for you may be to use the view scope for your beans. I think this is very common practice for pages that display collections of data. In this case the time of injection won’t really matter, because the beans keep their state.

    #21023

    Zhomart
    Participant

    Never heard about view scope =), anyway it would be expensive in my case, performance is really issue…

    Happy with trinidad’s iterator and render tags, but still sometimes you need c:if for putting f:param’s and stuff like that, correct me if I am wrong.

    If you guys will change that behavior, that would be great, and pls let me know. Because now I have to test every usage if c:if where I couldn’t get rid of it…

    Anyway, I think it would be more correct if bean’s would be “ready” before any usage.

    #21024

    If you would like to see this thing changed in PrettyFaces, just open a ticket:

    http://code.google.com/p/prettyfaces/issues/list

    This way you will be notified as soon as we close it! :)

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

You must be logged in to reply to this topic.

Comments are closed.