You need to associate the input value with the repeated variable var in some way. Right now you’re not doing that anywhere and basically binding all input values to one and same bean property. So, when the form gets submitted, every iteration will override the bean property everytime with the value of the current iteration … Read more
There’s physically only one UIInput component whose state changes depending on the current iteration round of UIRepeat. It’s available by just its client ID without the UIRepeat index: findComponent(“formId:inputId”) (the UIRepeat index is only of significance in the client side). However, when the component is programmatically been accessed outside the context of UIRepeat this way, … Read more
Just bind the table to the view itself instead of to a bean. <h:dataTable binding=”#{table}” …> Then you can use #{table.rowIndex} where necessary. E.g. <h:column>#{table.rowIndex + 1}</h:column> Note that the code is as-is and that the EL variable name table is fully to your choice. See also: How does the ‘binding’ attribute work in JSF? … Read more
Simplest way would be to just bind the value of the checkbox group to the currently iterated object instead of all checkbox groups to one and same parent bean property. In code, just replace value=”#{gridPopUpBean.oneQuestionUserAnswerList}” by value=”#{p.oneQuestionUserAnswerList}” and make changes in the model accordingly. Alternatively, you can also provide a Map of all answers by … Read more
This is a bug in state saving of <ui:repeat> in Mojarra. There are several similar issue reports at http://java.net/jira/browse/JAVASERVERFACES, among others issue 2243. You have basically 2 options: use another iterating component (e.g. <c:forEach>, <h:dataTable>, <t:dataList>, <p:dataList>, etc), or replace Mojarra by MyFaces (the <ui:repeat> in this construct works properly in there).
This is indeed specified/expected behavior. The attributes of taghandlers like <f:validateXxx> are evaluated during view build time. So they can’t refer a variable which is only available during view render time like the currently iterated variable of <ui:repeat>. It would indeed work when you use an iterator which runs during view build time like JSTL … Read more
What you need is to nest another <ui:repeat> tag in your outer iteration: <ui:repeat value=”#{bean.listOfA}” var=”a”> … <ui:repeat value=”#{a.listOfB}” var=”b”> … </ui:repeat> </ui:repeat> The only thing left that is worth noting is that nested <ui:repeat> tags used to have problems with state management until Mojarra 2.1.15 version (details in jsf listener not called inside nested … Read more
This is not possible with a render-time tag such as <ui:repeat>. The <ui:repeat> will however by itself already ensure the uniqueness of the generated client ID by prepending it with the row index. So just remove the EL part from the ID attribute of the component. <ui:repeat value=”#{bean.columns}” var=”column”> <h:panelGroup layout=”block” id=”column”> With a view … Read more
It is not possible to use <p:graphicImage> this way. You should rather iterate over a collection of unique image identifiers, not over a collection of StreamedContent. Those unique image identifiers have then to be passed as a <f:param> to <p:graphicImage> which in turn will generate the right URLs for the browser. <ui:repeat value=”#{data.imageIds}” var=”imageId”> <p:graphicImage … Read more
Not with JSTL tags, no. They run during view build time, not during view render time. You can visualize it as follows: when JSF builds the view, JSTL tags run from top to bottom first and the result is a pure JSF component tree. Then when JSF renders the view, JSF components run from top … Read more