I want to inlude <ui:include> one page dynamically several times.
Code:
<h:dataTable ..>
<h:column>
<ui:include src="#{create_page}">
<h:column>
<h:dataTable>
Now when I submit it persists only the last inlude. It remembers only the values for the last included page. I want unique entity object in each create_page. How can I do that?
The <ui:include> is as being a tag handler executed during view build time, while the <h:dataTable> is as being an UI component executed during view render time. This means that the <ui:include> is executed only once before the <h:dataTable> and thus not during the iteration. You effectively end up with exactly the same include source in every row. When the form is submitted the rows are processed one by one until the last row, that's why you effectively end up with the values of the last row.
There are basically 2 ways to solve this:
Use <c:forEach> instead of <h:dataTable>, this runs also during view build time.
Use a tag file or a composite component instead of <ui:include>, this runs also during view render time.
Either way, you also need to ensure that the input values are bound to the object behind the var attribute of the datatable, not to one and same backing bean property.
See also:
JSTL in JSF2 Facelets... makes sense? (the <ui:include> falls in the same category as JSTL)
When to use <ui:include>, tag files, composite components and/or custom components?
Related
So after several days of debugging, we were eventually able to reproduce some strange interactions between composite components, ui:repeat, p:remoteCommand and partial state saving in JSF that we do not understand.
Scenario
A composite component iterates over a list of objects using ui:repeat. During each iteration, another composite component is included and arguments are passed.
<ui:composition (...)>
<ui:repeat var="myVar" value="#{cc.attrs.controller.someList}">
<namespace:myRemoteCommand someParam="SomeParam"/>
In the included composite component, there is an auto-run p:remoteCommand calling a method using parameters defined in the component's interface.
<ui:component (...)>
<p:remoteCommand actionListener="#{someBean.someMethod(cc.attrs.someParam)}"
autoRun="true"
async="true"
global="false">
However, when setting a breakpoint in someMethod(...), an empty string is passed. This only happens if partial state saving is set to false.
Solutions
We tried several solutions and the following ones appear to work (however we do not understand why and cannot foresee any further problems that could occur):
We can set partial state saving to true.
We can change the composite component pattern to ui:include.
We can remove one or both of the composite components and directly include the content instead.
Question
Why does JSF behave this way? What is this interaction between composite component, ui:repeat and argument passing that changes depending on whether we use ui:include / partial state saving or not?
We're using Primefaces 5.3, Glassfish 4.1, Mojarra 2.2.12, Java 8.
Your code is all fine. It's just that Mojarra's <ui:repeat> is broken. You're not the first one facing a state management related problem with <ui:repeat>.
Checkbox inside ui:repeat not refreshed by Ajax
Dynamically added input field in ui:repeat is not processed during form submit
Components are with the same id inside ui:repeat
<h:form> within <ui:repeat> not entirely working, only the last <h:form> is processed
Composite component with custom backing component breaks strangely when nested inside ui:repeat
ui:repeat in o:tree not working as expected
Root cause of your problem is that #{cc} is nowhere available at the moment the <ui:repeat> needs to visit the tree. Effectively, the <ui:repeat value> is null. A quick work around is to explicitly push the #{cc} in UIRepeat#visitTree() method. Given Mojarra 2.2.12, add below lines right before line 734 with pushComponentToEL(facesContext, null).
UIComponent compositeParent = getCompositeComponentParent(this);
if (compositeParent != null) {
compositeParent.pushComponentToEL(facesContext, null);
}
And add below lines right after line 767 with popComponentFromEL(facesContext).
if (compositeParent != null) {
compositeParent.popComponentFromEL(facesContext);
}
If you don't build Mojarra from source, copy the entire source code of UIRepeat into your project, maintaining its package structure and apply above changes on it. Classes in /WEB-INF/classes have higher classloading precedence than those in /WEB-INF/lib and server's /lib. I have at least created issue 4162 to address this.
An alternative is to replace Mojarra by MyFaces, or to replace the <ui:repeat> by an UIData based component which got state management right such as <h:dataTable> or <p:dataList>.
<p:dataList type="none" var="myVar" value="#{cc.attrs.controller.someList}">
<namespace:myRemoteCommand someParam="SomeParam" />
</p:dataList>
You might only want to apply some CSS to get rid of widget style (border and such), but that's trivial.
See also:
Should PARTIAL_STATE_SAVING be set to false?
I have to dinamically produce a list of tables. Each of these have a variable number of columns (with fixed rows).
To perform this I first put a <p:panelGrid> inside an <ui:repeat>: so I correctly produced a list of tables.
Then, to dinamically produce the columns, I tried put both an <ui:repeat> or a <c:forEach> inside the <p:panelGrid>. In the result I obtain no rows.
I written a minimal example here. In the bean testBackingBean, I have defined (and initialized) the variable ArrayList<ArrayList<String>> tables. This is the xhtml that does not produce the expected results:
<ui:repeat var="table" value="#{testBackingBean.tables}">
<p:panelGrid>
<f:facet name="header">
<p:row>
<p:column >header of #{table}</p:column>
</p:row>
</f:facet>
<p:row>
<c:forEach var="row" items="${table}">
<p:column>#{row}</p:column>
</c:forEach>
</p:row>
</p:panelGrid>
</ui:repeat>
Noteworthy the header-row correctly converts #{table} into string. The problem is that I see no rows of data.
Also, if I use the <table> instead of the <p:panelGrid> everything work as excpected.
Also, I tried different permutations of <c:forEach> and <ui:repeat> with no succes.
So, how can I dinamically produce more tables (using prime-faces) and set a dinamical number of columns?
Thanks!
EDIT: I would like to use two <c:forEach>, but even with one only <c:forEach> I get an empty result. In fact if I try the following xhtml:
<c:forEach items="${testBackingBean.tables}" var="tabella">
current element: #{tabella}
</c:forEach>
then I get an empty result. (I know,this is a different question)
The transition from the XHTML source code to the generated HTML output is a two-step process.
First, during view build time, the XHTML source code is parsed and turned in a tree of Java UIComponent instances representing the JSF UI component tree, as available by FacesContext#getViewRoot().
Then, during view render time, the JSF UI component tree produces HTML output and writes it to the HTTP resopnse, starting with UIViewRoot#encodeAll() method.
Taghandlers like all JSTL <c:xxx> tags, several JSF <f:xxx> tags and only a few Facelets <ui:xxx> tags run during view build time. UI components like all JSF <h:xxx> tags, several Facelets <ui:xxx> tags and only a few JSF <f:xxx> tags run during view render time.
The <c:forEach> is a taghandler and the <ui:repeat> is an UI component.
In other words, the UI components which are declared inside <c:forEach> are recreated multiple times in the JSF component tree based on <c:forEach items> during view build time which in turn individually produce each their own HTML output during view render time. The UI components which are declared inside <ui:repeat> are created only once in the JSF component tree during view build time which in turn are reused multiple times based on <ui:repeat value> to produce HTML output during view render time.
Your concrete problem is caused by the fact that <ui:repeat var="table"> is only available during view render time, not during view build time. The <c:forEach> is basically retrieving a #{null} as value when it's about to run during view build time.
You can solve this by replacing the outer <ui:repeat> by <c:forEach>. Although I wonder if you couldn't better use <ui:repeat><p:dataTable><p:columns> instead.
See also:
JSTL in JSF2 Facelets... makes sense?
Is this legal?
<h:form id="status${a.myID}" >
// ...
</h:form>
where 'a' is an object in a backing bean. It seems to sort of work, but when I look at the rendered HTML, I see the id as: :0:status for example, instead of :status0 as I would expect. My main problem is trying to reference the id from <f:ajax render=.... I'm getting "contains an unknown id..." with pretty much every combination I can think of. Is it possible to set ids using values from a backing bean reliably?
The single-letter variable name ${a} and the symptom of an iteration index like :0 being auto-appended in client ID, suggests that this <h:form> is inside a JSF iterating component such as <h:dataTable> or <ui:repeat> with a var="a" which actually is not a backing bean. It would confirm and explain all symptoms described so far. If ${a} were a real backing bean (and not an iteration variable), then it would have "worked" and you would have seen :0:status0, :1:status0, :2:status0, etc — whose usefulness is questionable though.
First of all, the id attribute of a JSF component is evaluated and set during view build time, the moment when the JSF component tree is to be built based on XHTML source code file. The var attribue of a JSF iterating component is set during view render time, the moment when the HTML output is to be generated based on JSF component tree. Thus, logical consequence is, the object set by var attribute is not available at the moment the id attribute needs to be set and thus evaluates to null/empty-string. The effect is exactly the same as when you would do
<h:form id="status">
JSF iterating components namely already auto-appends the iteration index to the generated client ID. It would not make any sense to manually set the ID of the iterated item in the component ID. There's namely physically only one <h:form> component in the JSF component tree which is in turn reused multiple times during producing the HTML output based on the current iteration round.
This Q&A should also give more food for thought: JSTL in JSF2 Facelets... makes sense?
Coming back to your concrete functional requirement of referencing a component in <f:ajax render>, you definitely need to solve this differently. Unfortunately you didn't clearly describe the context of the source component and the target component, so it's impossible to give/explain the right client ID and so I'm just giving you a link so that you can figure it out on your own: How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"
Unrelated to the concrete problem, the old JSP EL style ${...} has in Facelets exactly the same effect as #{...}. In order to avoid confusion by yourself and your future maintainers it's recommend to completely ban usage of ${...} and stick to #{...} all the time. See also Difference between JSP EL, JSF EL and Unified EL
Actually ${a.myID} this is not rendering any output. As you are getting :0:status as form ID which implies, :0 is parent of :status in HTML tree structure.
Using JSF 2.0, I need to display a table wherein each row contains a link which opens a popup. I have two models: A which has id and List<B> properties and B which has id and name properties. In my backing bean, I have a List<A> property. In my view, I am using <ui:repeat> to iterate over List<A>.
The requirement is, depending on the row that the user clicks, the corresponding List<B> of A needs to be displayed. However, the <ui:repeat> does not accept a nested list to be assigned in the var attribute. Hence, I need to do a lot of workarounds which is not efficient.
How do I efficiently solve this problem?
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 ui:repeat and in many not so recent questions and their answers), which could result in action listeners not called, etc. but if you're currently on the latest Mojarra JSF implementation - just skip this part altogether.
Let's say I am using rendered as basically a case statement. I have a label and message for an input field, but I want the field itself to change depending on the case. As such:
<p:inputText id="foo" value="#{myBean.params[paramKey]}"
rendered="#{paramIsInput}" />
<p:calendar id="foo" value="#{myBean.params[paramKey]}"
rendered="#{paramIsCalendar}" />
If I do that then I get the following error: java.lang.IllegalStateException: Component ID j_idt64:foo has already been found in the view.
As a workaround I created lots of labels/messages for each param type and changed their ids. But this brings my question. If only one component with an id is actually rendered, why would it matter that I have multiple defined in my jsf file? Is there a way to keep them with all the same ID?
JSF component IDs are supposed to be unique during view build time already, not during view render time only. This way you effectively end up with two JSF components with the same ID which is indeed invalid. You'd like to effectively end up with one JSF component with the desired ID in the JSF component tree after view build time.
You can achieve this by populating the component during the view build time instead of generating its HTML output conditionally during the view render time. You can use the JSTL <c:if> tag for this.
<c:if test="#{paramIsInput}">
<p:inputText id="foo" value="#{myBean.params[paramKey]}" />
</c:if>
<c:if test="#{paramIsCalendar}">
<p:calendar id="foo" value="#{myBean.params[paramKey]}" />
</c:if>
This has however caveats: the <c:if test> condition can't depend on a variable which is only known during JSF render time. So it has not to depend on var of a JSF iterating component, or to be a property of a view scoped bean, etc.
See also:
JSTL in JSF2 Facelets... makes sense?
If only one component with an id is actually rendered, why would it matter that I have multiple defined in my jsf file?
How would JSF know that only one component will be rendered? You are using EL in rendered and both can evaluate to true. Here is the documentation which says you can't have duplicate ids inside a naming container.
The specified identifier must be unique among all the components (including facets) that are descendents of the nearest ancestor UIComponent that is a NamingContainer, or within the scope of the entire component tree if there is no such ancestor that is a NamingContainer.
-
Is there a way to keep them with all the same ID?
In case you still want to have same ids on more than one components you need to separate the naming container.
You can use PanelGrid as a naming container.