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 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).
You need to realize that the <p:graphicImage> actually renders a <img src> element with just an URL which is then later individually invoked by the webbrowser when it’s about to parse the obtained HTML markup and present the results. So, whatever you do in the getter method of <p:graphicImage> it must be designed that way … 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
To the point, you expected that the converter’s properties are set every time a datatable row is rendered. This is indeed not true. JSF will create only one converter instance per component when the view is to be built, it will not create/reset the converter each time the row is rendered. There are several ways … Read more
Your best bet is to bind the <h:selectBooleanCheckbox> value with a Map<Item, Boolean> property where Item represents the object behind the corresponding row. <h:dataTable value=”#{bean.items}” var=”item”> <h:column> <h:selectBooleanCheckbox value=”#{bean.checked[item]}” /> </h:column> … </h:dataTable> <h:commandButton value=”submit” action=”#{bean.submit}” /> public class Bean { private Map<Item, Boolean> checked = new HashMap<Item, Boolean>(); private List<Item> items; public void submit() … Read more
The String class is immutable and doesn’t have a setter for the value. The getter is basically the Object#toString() method. You need to get/set the value directly on the List instead. You can do that by the list index which is available by <ui:repeat varStatus>. <ui:repeat value=”#{mrBean.stringList}” varStatus=”loop”> <h:inputText value=”#{mrBean.stringList[loop.index]}” /> </ui:repeat> You don’t need … Read more