1

OK, I'm guessing that this might be a bug but I'm not totally sure. Can anyone see what I'm doing wrong?

Here's the situation. I have a composite component that seems to work perfectly when it's alone on the page. The problem comes when the component is nested inside of a ui:repeat. Here are the two places I am calling the component (just for a test):

<q:case aCase="#{userSummaryBackingBean.userCases.get(0)}">

    <f:setPropertyActionListener for="clickEvent" target="#{userSummaryBackingBean.value}" value="single"/>
    <f:ajax execute="@this" render="@this :westPaneForm"/> 

</q:case>


<ui:repeat value="#{userSummaryBackingBean.userCases}" var="aCase">
    <li>
    <q:case aCase="#{aCase}">
        <f:setPropertyActionListener for="clickEvent" target="#{userSummaryBackingBean.value}" value="repeat"/>
        <f:ajax execute="@this" render="@this :westPaneForm"/>                                                                     
    </q:case>
    </li>
</ui:repeat>

and the component is defined as follows:

<cc:interface>
    <cc:attribute name="aCase" type="com.autonomy.calltrack.data.dto.Case"/>
    <cc:actionSource name="clickEvent" targets="caseCommandLink"/> 
    <cc:attribute name="action" targets="caseCommandLink" />
    <cc:attribute name="actionSource" targets="caseCommandLink" />
    <cc:clientBehavior name="click" event="action" targets="caseCommandLink" default="true"/>
</cc:interface>

<cc:implementation>


<h:commandLink id="caseCommandLink" styleClass="case ui-state-default" title="#{cc.clientId}">


--- more code ---

</h:commandLink>

</cc:implementation>

As you can see, the calls are exactly the same but the single item works and the items in the ui:repeat do not. Now, it makes sense to me that things will be problematic when the component itself has a ui:repeat. I mean, how would you retarget your actionSource, etc without knowing the ID of the items you need (which, inside of the repeat, is basically impossible).

HOWEVER, when I put the ui:repeat outside of the component I can't wrap my head around why things wouldn't work. The REALLY odd thing is that the f:ajax seems to work totally fine. VERY odd.

I've tried prefixing the targets attributes with :#{cc.clientId} and that doesn't help either (even though the "path" to the components is correct). Am I doing something wrong? Does anyone have a solution?

Alright, something must be wrong because even this doesn't work:

<ui:repeat value="#{userSummaryBackingBean.userCases}" var="aCase">

        <h:commandLink id="caseCommandLink" value="test" styleClass="case ui-state-default">
            <f:setPropertyActionListener target="#{userSummaryBackingBean.value}" value="REPEAT"/>
            <f:ajax execute="@this" render="@this :westPaneForm"/>       

        </h:commandLink>

</ui:repeat>

What the heck could I be missing?

jjross
  • 678
  • 1
  • 6
  • 19
  • 1
    What JSF impl/version are you using? I can't reproduce your problem on Mojarra 2.1.3. Noted should be that `` is really an odd beast and has been fixed/improved a lot throughout the Mojarra 2.x lifetime. A much better choice would be a fullworthy JSF `UIData` component which renders an `
    • ` like Tomahawk's ``, PrimeFaces' ``, RichFaces' ``, etc.
     – BalusC Oct 13 '11 at 19:55
  • I'm using 2.0.6 because 2.1.3 isn't supported on Tomcat. I guess I could try switching to 2.1.3 with Glassfish I just don't have any experience with GF. I'll also try the UIData option. Thanks! – jjross Oct 13 '11 at 20:15
  • 1
    Ok, I tried with the and it didn't seem to make a difference. I guess I'll try the upgrade. Unless I have to change something to make it work in the . I left the section the same. – jjross Oct 13 '11 at 20:25
  • 2.1.3 is definitely supported on Tomcat. Perhaps you're confusing with 2.1.0 which indeed contained a major bug in annotation scanner (it contained Glassfish specific code and it was fixed asap for 2.1.1). – BalusC Oct 13 '11 at 23:48
  • Really? Because when I looked at the list of known issues it says that it is "not known to work on Tomcat". From here: http://javaserverfaces.java.net/nonav/rlnotes/2.1.3/issues.html – jjross Oct 14 '11 at 14:52
  • Must be their mistake. Perhaps they copied 2.1.0 release notes and overlooked that entry. It works for me from 2.1.1 on. To be precise, it's issue 1937 which was fixed in 2.1.1. – BalusC Oct 14 '11 at 14:57

1 Answers1

0

My page was using view params but they weren't a child of f:view so they were causing problems.

When I moved them everything started to work normally. I'm not sure why but it seems that things break when you have something like the following outside of an f:view:

<f:metadata>
    <f:viewParam name="caseId" value="#{caseBackingBean.viewingCaseNumber}" />

</f:metadata>
<f:event type="preRenderView" listener="#{caseBackingBean.loadCase}" />

Thanks for the help BalusC.

jjross
  • 678
  • 1
  • 6
  • 19
  • The `preRenderView` is invoked on every postback. Perhaps you're reloading the list with different content or even clearing it which caused that `` doesn't get the correct value anymore? If the bean is view scoped, you could add `if (!FacesContext.getCurrentInstance().isPostback()) { /* Original code here */ }` – BalusC Oct 17 '11 at 19:32
  • Well actually the method wasn't even being called. I put a break point in the debugger and it never hit while the component was in a repeat. Worked fine when outside of the repeat though... – jjross Oct 17 '11 at 21:23
  • Ah well. Did you take into account that `` does not work in master template files? (the one which you reference by ``). It has to go in the top level view template. See also its tag documentation: http://download.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/f/metadata.html – BalusC Oct 18 '11 at 00:00
  • Hmmm. I wonder if that was a factor. I'll have to test and see what I can find. I might have been using that tag wrong. – jjross Oct 18 '11 at 15:27
  • OK, this wasn't a bug at all. Looks like I had the metadata in the wrong place AND my was a child of . Once I moved things around (as per your link) they started to work. The only issue is that when I click on a link and then go back to the page I can't click another link. This isn't a problem when the page is session scope. It only happens with view scope. Oh well, I'll keep working at it. – jjross Oct 19 '11 at 03:38