In JSF, <ui:repeat/> and similar components such as PrimeFaces <p:dataTable/> generate dynamic ids for sub-components based on the iteration index, i.e.:
<p:dataTable id="table" var="item" value="#{itemList}">
<h:outputText id="name" value="#{item.name}"/>
</p:dataTable>
will generate something like this:
<table id="table">
<span id="table:0:name">name0</span>
<span id="table:1:name">name1</span>
<span id="table:2:name">name2</span>
...
<span id="table:n:name">nameN</span>
</table>
so all the elements clearly have a distinct client id. I intentionally skipped the <tr/>, <td/>, etc.
So, <p:ajax ... update=":table:name"/> refers to all the names in the table and it works fine, <p:ajax ... update=":table:#{someDesiredIndex}:name"/> fails with a message similar to SEVERE: javax.faces.FacesException: Cannot find component with identifier ":table:0:name" in view. event though I can confirm that the component exists in the markup. Is it not possible to do this?
I'm running on GlassFish 3.1.2 and Mojarra 2.1.6 in case it is relevant.
It does indeed not exist in the JSF component tree as traversable by UIViewRoot#findComponent(). It exists only in the generated HTML output. There's only one <h:outputText id="name"> in the JSF component tree, not multiple as you seemed to expect. It's just been reused multiple times when producing the HTML output. At best, you can get the physical component by table:name, but this does in turn not exist in the HTML DOM tree, so the document.getElementById() would fail on that during performing the ajax update.
In order to achieve the concrete functional requirement anyway, you basically need to have a physical existing component representing the row in the JSF component tree. You can create them in a loop if you use a view build time tag, such as JSTL <c:forEach>, instead of a view render time tag.
<table id="table">
<c:forEach items="#{itemList}" var="item" varStatus="loop">
<tr><td><h:outputText id="table_#{loop.index}_name" value="#{item.name}" /></td></tr>
</c:forEach>
</table>
This will create physically multiple components in the JSF component tree and this get rendered as:
<table id="table">
<span id="table_0_name">name0</span>
<span id="table_1_name">name1</span>
<span id="table_2_name">name2</span>
...
<span id="table_n_name">nameN</span>
</table>
And you can reference them via e.g. update=":table_#{someDesiredIndex}_name".
See also:
How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"
JSTL in JSF2 Facelets... makes sense?
Update: since Mojarra 2.2.5, the <f:ajax> doesn't validate the client ID anymore and the renderer is capable of walking through iterating components in order to find the right iteration round to render. So referencing the iteration index in <f:ajax> this way should just work fine. It only doesn't work yet in current MyFaces 2.2.7 / PrimeFaces 5.1 versions, but it's expected that they will catch up it in a future version.
Related
I'm just learning JSF 2 thanks to this site I had learned a lot in such a short time.
My question is regarding how to implement a common layout to all my JSF 2 pages and have only the content part of the page refresh not the whole page whenever I click a link/menu from a different panel. I am using the Facelets approach it does what I want except that each time I click a link from a panel (e.g. menu items from left panel) the whole page is refreshed. What I am looking for is a way to refresh only the content part of my page. To illustrate this below is my target pagelayout.
Did not post my code because I'm not sure if Facelets can do this . Are there other approach more suited for my requirement other than Facelets?
A straightforward approach would be the following view:
<h:panelGroup id="header" layout="block">
<h1>Header</h1>
</h:panelGroup>
<h:panelGroup id="menu" layout="block">
<h:form>
<f:ajax render=":content">
<ul>
<li><h:commandLink value="include1" action="#{bean.setPage('include1')}" /></li>
<li><h:commandLink value="include2" action="#{bean.setPage('include2')}" /></li>
<li><h:commandLink value="include3" action="#{bean.setPage('include3')}" /></li>
</ul>
</f:ajax>
</h:form>
</h:panelGroup>
<h:panelGroup id="content" layout="block">
<ui:include src="/WEB-INF/includes/#{bean.page}.xhtml" />
</h:panelGroup>
With this bean:
#ManagedBean
#ViewScoped
public class Bean implements Serializable {
private String page;
#PostConstruct
public void init() {
page = "include1"; // Default include.
}
// +getter+setter.
}
In this example, the actual include templates are include1.xhtml, include2.xhtml and include3.xhtml in /WEB-INF/includes folder (folder and location is fully free to your choice; the files are just placed in /WEB-INF in order to prevent direct access by guessing the URL in browser's address bar).
This approach works in all MyFaces 2.x versions, but requires in case of Mojarra a minimum of 2.3.x. In case you're using a Mojarra version older than 2.3.0, then this all fails when the <ui:include> page in turn contains a <h:form>. Any postback will fail because it is totally missing the view state. You can solve this by upgrading to minimally Mojarra 2.3.0 or with a script found in this answer h:commandButton/h:commandLink does not work on first click, works only on second click. Or, if you're already using PrimeFaces and exclusively use <p:xxx> ajax, then it's already transparently taken into account.
Also, make sure that you're using minimally Mojarra 2.1.18 as older versions will fail in keeping the view scoped bean alive, causing the wrong include being used during postback. If you can't upgrade, then you'd need to fall back to the below (relatively clumsy) approach of conditionally rendering the view instead of conditionally building the view:
...
<h:panelGroup id="content" layout="block">
<ui:fragment rendered="#{bean.page eq 'include1'}">
<ui:include src="include1.xhtml" />
</ui:fragment>
<ui:fragment rendered="#{bean.page eq 'include2'}">
<ui:include src="include2.xhtml" />
</ui:fragment>
<ui:fragment rendered="#{bean.page eq 'include3'}">
<ui:include src="include3.xhtml" />
</ui:fragment>
</h:panelGroup>
The disadvantage is that the view would become relatively large and that all associated managed beans may be unnecessarily initialized even though when they would not be used as per the rendered condition. See also JSTL in JSF2 Facelets... makes sense? for an in depth explanation on <ui:include src="#{...}"> vs <x:someComponent rendered="#{...}">.
As to positioning of the elements, that's just a matter of applying the right CSS. That's beyond the scope of JSF :) At least, <h:panelGroup layout="block"> renders a <div>, so that should be good enough.
Last but not least, this SPA (Single Page Application) approach is not SEO friendly. All the pages are not indexable by searchbots nor bookmarkable by endusers, you may need to fiddle around with HTML5 history in client and provide a server side fallback. Moreover, in case of pages with forms, the very same view scoped bean instance would be reused across all pages, resulting in unintuitive scoping behavior when you navigate back to a previously visited page. I'd suggest to go with templating approach instead as outlined in 2nd part of this answer: How to include another XHTML in XHTML using JSF 2.0 Facelets? See also How to navigate in JSF? How to make URL reflect current page (and not previous one).
If you only want to refresh part of the page, there are only 2 ways to go (for the web in general, not just JSF). You have to use frames or Ajax. JSF 2 supports ajax natively, check out the f:ajax tag to update just 1 component without reloading the entire page.
Netbeans provides a wizard that create the proposed layout with minimal effort using JSF. So, the best way to start is take a look at Facelets Template Wizard and look at the generated source.
can I pass expressions to JSF 2 passthrough-attributes?
the following code is not working. expression #{country.isoCode} is not evaluated.
<h:selectOneMenu value="#{bean.selectedCountry}" styleClass="selectlist">
<f:selectItems
value="#{bean.countries}" var="country"
itemLabel="#{country.countryName}"
pt:data-icon="flag flag-#{country.isoCode}"/>
</h:selectOneMenu>
I am using namespace
xmlns:pt="http://xmlns.jcp.org/jsf/passthrough"
and bootstrap-select. attribute "data-icon" is used to show an image. see:
http://silviomoreto.github.io/bootstrap-select/#data-icon
rendered output:
<i class="glyphicon flag flag-"></i>
EL is basically supported/evaluated over all place in a Facelet template. Also outside tags/attributes. Even in HTML comments, where many starters then fall over. So that's not the problem.
Your particular case is, unfortunately, "by design". Before rendering the first <option> element, the <f:selectItems> is is wholly parsed only once and turned into an iterator during which all EL expressions will be evaluated. Then, the component will iterate over it while rendering <option> elements during which all passthrough attributes will be evaluated. However, as the var was already evaluated during creating the iterator, it isn't available anywhere during rendering the passthrough attributes and ultimately evaluates to an empty string.
Fixing that would require quite some changes in standard JSF implementation of <f:selectItems>. I'm not sure if JSF guys would be all ears for that, but you can always try to create an issue.
You can work around this by creating physically multiple <f:selectItem> instances during view build time, with help of <c:forEach>.
<h:selectOneMenu ...>
<c:forEach items="#{bean.countries}" var="country">
<f:selectItem
itemValue="#{country}"
itemLabel="#{country.countryName}"
pt:data-icon="flag flag-#{country.isoCode}" />
</c:forEach>
</h:selectOneMenu>
See also:
JSTL in JSF2 Facelets... makes sense?
I have page where I render some h:panelGroup panels. Those panels are realized as plugins registered in a plugin registry on startup.
Part of the plugins api is a custom jsf component where I get the registered plugins for extension point and include their facelet templates by path:
<c:forEach items="#{pluginRegistry.getPlugins(point)}" var="extension">
<ui:include src="#{extension.path}" />
</c:forEach>
The page where I include the panels looks like:
<h:panelGrid id="dashboard" columns="3">
<cmf:insertPageFragments point="dashboardExtensionPoint" />
</h:panelGrid>
For every panel there are facelet templates like the one below:
<rich:panel id="caseDetailsPanel" header="panel label">
<!-- panel content -->
</rich:panel>
Now, the problem is that the very first panel in the list returned by the pluginsRegistry is rendered in the page with the provided id like formId:caseDetailsPanel for example. The rest of them have generated ids like formId:j_idt223 !!! Obviously if I want to rerender some of the panels, I can't do that.
That happens when environment is jboss AS 7.1 with JSF 2.1, richfaces 4.2.3.Final.
When deployed on jboss-eap-6.1 everything looks fine but for now I can't use this jboss version.
Any suggestions on how to workaround this issue?
There can not be multiple JSF components with the same ID. Each JSF component must have an unique ID. When dynamically creating JSF components using JSTL, you need to manually assign and ensure an unique ID, otherwise JSF will discard the provided ID and autogenerate an unique ID.
There are several ways to achieve this, depending on the concrete functional requirement and the existing code.
Use use the iteration index of <c:forEach>.
<c:forEach ... varStatus="loop">
...
<rich:panel id="caseDetailsPanel_#{loop.index}" ...>
This will generate caseDetailsPanel_0, caseDetailsPanel_1, etc depending on the current iteration index.
Use the unique identifier of the currently iterated item. It isn't clear based on the information provided so far if you have any, so here's just a fictive example assuming that the class behind #{extension} has an id property representing the technical DB identifier.
<c:forEach ... var="extension">
...
<rich:panel id="caseDetailsPanel_#{extension.id}" ...>
Wrap #1 or #2 if necessary in a <f:subview> with an unique identifier, so that you don't need to modify the includes.
<c:forEach ... varStatus="loop">
<f:subview id="panel_#{loop.index}">
<ui:include ... />
The <f:subview> creates a new NamingContainer around it, so you end up getting formId:panel_0:caseDetailsPanel, formId:panel_1:caseDetailsPanel and so on.
A completely different alternative would be to use <ui:repeat> instead of <c:forEach>. The <ui:repeat> does not run during view build time, but during view render time. This way there's physically only one <rich:panel id="caseDetailsPanel"> component in the component tree which is reused multiple times during generating HTML whereby JSF will take care of generating the right IDs with the <ui:repeat> index like so formId:repeatId:0:caseDetailsPanel. However, this in turn may cause trouble with <ui:include> as it also runs during view build time and thus can't get the #{extension} at hands.
I am using ui:repeat tag which render images. I have five images i want that on each iteration my image get ids like image1, image2, image3.... imagen. I tried this but it is not working.
<div id="imageGallery">
<ui:repeat value="#{countryPages_Setup.images}" var="image" varStatus="status">
<tr>
<td>
<a href="javascript:void()" class="launchLink">
<p:graphicImage id="image#{status.index}" //problem
value="/resources/images/#{image}"
width="100"
height="100"
rendered="#{countryPages_Setup.renderImages}"/>
</a>
</td>
</tr>
</ui:repeat>
</div>
I also tried {staus.index + 1}. I also tried id= image#{1++} But it is also not working. How can i do it?
Thanks
You can use EL in the id attribute, but it has to be available during view build time. The <ui:repeat> however runs during view render time, it will reuse the same <p:graphicImage> to generate multiple HTML <img> elements. It doesn't run during view build time, so the id remains image.
If you replace <ui:repeat> by <c:forEach>, then it'll work as you intented. The <c:forEach> runs during view build time and it will generate multiple <p:graphicImage> components which will then each get rendered only once.
<div id="imageGallery">
<c:forEach items="#{countryPages_Setup.images}" var="image" varStatus="status">
<tr>
<td>
<a href="javascript:void()" class="launchLink">
<p:graphicImage id="image#{status.index}"
name="images/#{image}"
width="100"
height="100"
rendered="#{countryPages_Setup.renderImages}"/>
</a>
</td>
</tr>
</c:forEach>
</div>
You cannot use el expressions within the id attribute. It needs to be static. The ui:repeat itself generates a prefix to your id. You don't need to care about uniqueness.
So, for instance if you have an id="image", then the generated ids are
somePrefix:0:image, somePrefix:1:image, ...
But you can use variable in Javascript, for example:
<h:graphicImage ... onclick="top.location.href='http://blabla.com/imageclicked?id=#{status.index}'"/>
You can also use Variables with event handlers (since JSF 2.0):
<h:commandLink ... action="#{myBean.imageClicked(status.index)"/>
But your loop with c:forEach can cause problems. Be aware that the JSTL tags (everything that begins with c:) are not fully compatible to JSF. If you have luck, then they work as expected. But anyways the slow down the rendering engine, since the page gets processed multiple times by the JSF and JSP rendering engine.
Better use ui:repeat.
Just change <ui:repeat> to <c:forEach>
What I would like to achieve is to be able to address some JSF components from within other naming container.
Usecase: composite component which encapsulates some features using - for a field which is defined out of the composite component.
Some code:
<form id="foo">
...
<label for="nameTxt">Name:</label>
<component:customError forField="nameTxt" />
<h:inputText id="nameTxt" />
...
</form>
and the component:
<composite:implementation>
<h:panelGroup id="errorComponent">
...
<h:message for="#{cc.attrs.forField}" id="errorMsg" style="display:none;" />
...
</h:panelGroup>
</composite:implementation>
The problem is that on rendering the message I get:
Could not render Message. Unable to find component 'nameTxt' (calling findComponent on component 'j_id963445801_469fc056:errorMsg')
I think I understand that the problem lies in the fact the the field "nameTxt" and the message "errorMsg" lie in other naming-containers. So what I would have and like to do is to specify the path/id of "nameTxt" in relation to some common ancestor.
After studying shortly the algorithm UIComponentBase:findComponent I do not actually see any other way of adressing cross naming-containers than by specyfing whole (absolute) id-path from the root (i.e. ":foo:...:nameTxt"). And this is both clumsy and prone for errors after changing the page structure.
So - how to address properly the field "nameTxt" from within the message in the composite component?
I can reproduce your problem on MyFaces 2.1.3, but not on Mojarra 2.1.4 (and also not on older Mojarra 2.0.2). This is likely a bug in MyFaces, you'd need to report it to the MyFaces guys. In the meanwhile, I don't see any other option than (temporarily) replacing the JSF implementation by Mojarra. It has however its own share of issues as well, mainly with its broken <ui:repeat> and partial state saving implementations.
Update: I found a workaround, it's however a bit clumsy:
<component:customError forField=":#{nameTxt.clientId}" />
<h:inputText id="nameTxt" binding="#{nameTxt}" />
This will lookup using the absolute client ID instead of relative client ID. You'd only need to remove style="display:none" from your <h:message> to solve a different matter.