I just started out using JSF 2.0 but I found myself mixing JSF tags with standard HTML tag
to achieve the desired layout.
Although I am using the facelets to layout my pages, but I think I cant help but mix components.
<ui:define name="content">
<h:form>
<h:commandButton value="Search" action="#{myBean.handleSearch}"/>
<h:commandButton value="Reset" action="#{myBean.handleReset}"/>
<div>
<!-- Some JSF component -->
</div>
I have been thinking if I have been running into bad practice. Any source of info for this?
Thanks
This is not a bad practice. This is perfectly fine. The only reason to use a JSF component is to have access to it in the JSF component tree. It would be a more poor practice to use <h:panelGroup layout="block"> instead of <div> here. But if it was a container of which you'd like to ajax-update its content, then a <h:panelGroup id="foo" layout="block"> would have been perfectly fine as would an 'html5-friendly' <div jsf:id="foo"> with the xmlns:jsf="http://xmlns.jcp.org/jsf" namespace.
For a bit of history, you may find this useful: JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY?
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.
This example is from a book on JSF. The excercise is to refactor the following Facelets code while eliminating <c:if> and fn:toUpperCase(). Usage of <c:forEach> is allowed.
#{myBean.numbers} returns String["one","two","three"]
As the book is on JSF and not on Java, I suppose the existing Java-code is not to be touched. But I can't think of another way to do this solely in Facelets.
<c:forEach var="item" items="#{myBean.numbers}">
<c:if test="#{not fn:endsWith(item,'o')}">
#{item}
</c:if>
<c:if test="#{fn:endsWith(item,'o')}">
#{fn:toUpperCase(item)}
</c:if>
</c:forEach>
Only thing I can think of is using a converter that conditionally uses String#toUpperCase() and then I still do not understand why use of <c:forEach> should still be allowed:
<ui:repeat var="item" value="#{myBean.numbers}">
<h:outputText value="#{item}" converter="conditionalConverter"/>
</ui:repeat>
Is there a more "Facelets way" to do this (and still a need to use <c:forEach>)?
UPDATE:
Instead of <c:if> one could still use e.g. <h:outputPanel> and it's rendered-attribute, but there is still no Java-less replacement for fn:toUpperCase().
I am asking for learning purposes only. I suppose the <ui:repeat>-solution with a converter is the cleanest and represents most how JSF is supposed to be used. Do you think so, too?
As to <c:if>, the JSF alternative to JSTL <c:if> is the rendered attribute on any component. For example, <h:panelGroup> or <h:outputText>. Those components doesn't generate additional markup if there are no attribtues specified which should end up in HTML, like id or styleClass, otherwise they generate a <span>.
Here's an example of both:
<h:panelGroup rendered="#{not fn:endsWith(item,'o')}">
#{item}
</h:panelGroup>
<h:outputText value="#{fn:toUpperCase(item)}" rendered="#{fn:endsWith(item,'o')}" />
As to fn:toUpperCase(), JSF has no alternative. I'm not sure why you would need a JSF alternative as it's essentially not a tag, but a simple EL function which is perfectly usable in both JSTL and JSF tags. In any case, you could if necessary throw in CSS text-transform: uppercase. As this takes place entirely client side, your only problem may be the browser support.
<h:outputText value="#{item}" style="text-transform: uppercase" />
(note: this is just an example, the normal practice is to put styles in its own .css file which you load by <h:outputStylesheet>)
<h:outputText value="#{item}" styleClass="uppercased" />
I suppose the -solution with a converter is the cleanest and represents most how JSF is supposed to be used. Do you think so, too?
I'm a big fan of "Use the right tool for the job". Use JSTL tags to conditionally build the JSF component tree. Use JSF components to generate HTML. That's it. See also JSTL in JSF2 Facelets... makes sense?
I would like to add a header and footer image to a h:message in JSF 2.0 so it has nice borders.
It looks like the way to do this is to implement a custom renderer for a component and write out the tags. Id like to do this as a composite component but I cant figure out how to say 'dont draw the header and footer unless youre drawing the message'.
Is there a way to do this with a composite component?
Im using mojarra.
You can use FacesContext#messageList(String clientId) to get a List<FacesMessage> with all messages for a specific client ID (of which you'd usually be interested in only the first one, you can change the below example if you want). So you could just check in the rendered attribtue if the list is not empty. Then you can use <h:outputText escape="false"> to display the message without implicitly escaping HTML. You could if necessary wrap it all in a composite to keep your code DRY.
<h:inputText id="input1" binding="#{input1}" value="#{bean.input1}" />
<ui:param name="input1Messages" value="#{facesContext.messageList(input1.clientId)}" />
<h:panelGroup rendered="#{not empty input1Messages}">
<h3>Some header</h3>
<p><h:outputText value="#{input1Messages[0].summary}" escape="false" /></p>
<p>Some footer</p>
</h:panelGroup>
Note that this method was not available in JSF 1.x, that's why you'd need to create a custom component for it.
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.
I'm using Richfaces 4 CR1 + JSF 2.0. And I have got two questions :
1) I know nesting is not allowed in JSF. It just isn't.
Here's a use case - I have a master page which includes header.xhtml and footer.xhtml with
<ui:include src="header.xhtml"/>
<h:form>
<rich:tabPanel switchType="ajax"..>
<rich:tab ..>
<ui:include src="/includes/page1.xhtml" .../>
</rich:tab>
<rich:tab ..>
<ui:include src="/includes/page2.xhtml" .../>
</rich:tab>
</rich:tabPanel>
</h:form>
<ui:include src="footer.xhtml" .../>
The <rich:tabPanel ../> needs to wrapped with a <h:form.../>. And since each of my tab is actually another xhtml page, some of them have controls like <rich:togglePanel ../> which also requires a <h:form ../> tag around it...!
So how do I handle this in the best possible way?
PS : I have referred to this question and may be even my question's answer lies in <a4j:region ../>
2) How do I use a4j:push in Richfaces 4? The documentation is still in progress. The sample code is here but I couldn't understand the following line -
<a4j:push address="#{channelName}#chat" .. />
Any help with these two is greatly appreciated! :)
Answers to above questions given by Max Katz in an email chain were
1) Use a global form. When you submit, only the current active tab components will be processed
2) Max Katz, Ilya Shaikovsky and guys at Exadel/Richfaces were kind enough to publish a how-to on ajax:push here
Can't thank them enough! :)