Friday, September 16, 2011

Communication in JSF 2.0

Introduction

We assume that you're familiar with JSF basics. We assume that you're able to create JSF forms and beans like as demonstrated in the JSF 2.0 tutorial of this blog (model, view and controller). We assume that you've configured JSF to interpret empty string submitted values as null by the following context parameter in web.xml:


    <context-param>
        <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
        <param-value>true</param-value>
    </context-param>

The above will prevent that model values get littered with empty strings when the enduser leaves input fields empty. If you're running Tomcat or a clone/fork of it (e.g. JBoss AS, WebSphere AS, etc) or at least a servletcontainer which utilizes Apache EL parser, then we also assume that you've the following startup VM argument set:

-Dorg.apache.el.parser.COERCE_TO_ZERO=false

This will prevent that the aforementioned context parameter will fail for primitive wrapper managed bean properties (e.g. Long, Integer, Double, Boolean, etc), because this EL parser would immediately coerce an empty string to the wrapped primitive's default value such as 0, 0.0 or false before returning the value to JSF. Glassfish for example does not have this problem.

The code examples throughout the article are wherever applicable created and tested on Mojarra 2.1.3 and Glassfish 3.1.1 which are at the time of writing just the newest available. They should work equally good on older or newer versions or different implementations of JSF 2.x (MyFaces, for example) and/or servlet containers (Tomcat, JBoss, etc), unless explicitly otherwise mentioned. Any error/exception message examples are Mojarra 2.1.3 specific and may (slightly) differ on different versions and implementations.

The difference between JSF 2.0 and JSF 2.1 is subtle. As to compatibility, it's important to know that JSF 2.1 is targeted on Servlet 3.0 containers (Glassfish 3, Tomcat 7, JBoss AS 6, etc), while JSF 2.0 is targeted on older Servlet 2.5 containers (Glassfish 2, Tomcat 6, JBoss AS 5, etc). Most notable is Mojarra version 2.1.0; this version does not work on Tomcat/Jetty due to a major bug in the annotation scanner. This has been fixed in Mojarra 2.1.1.

Back to top

Managed bean names

You probably already know that you can annotate backing beans as managed bean with @ManagedBean and specify the managed bean name by the name attribute of the annotation without the need to specify them as <managed-bean> boilerplate in faces-config.xml like as in legacy JSF 1.x.

package com.example.controller;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;

@ManagedBean(name="bean")
@RequestScoped
public class Bean {

    // ...

}

This way the managed bean is available in EL by #{bean}. But do you also know that JSF will already implicitly use the bean's name with 1st character lowercased (at least, conform the property naming as stated in the Javabeans specification) when you omit the name attribute altogether?

package com.example.controller;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;

@ManagedBean
@RequestScoped
public class Bean {

    // ...

}

Make use of it and don't repeat yourself!

Back to top

Managed bean naming conventions

As to naming conventions, there is no strict convention specified by JSF itself. I've seen the following conventions:

  • Foo
  • FooBean
  • FooBacking
  • FooManager
  • FooController
  • FooBackingBean
  • FooManagedBean
  • FooBB
  • FooMB

FooBean is too vague. Really a lot of classes can be marked as javabeans. JSF managed beans, JPA entities, EJBs, service classes, data transfer objects, value objects, etc. The Bean suffix does not indicate the real responsibility of the class in any way. True, I use often MyBean or Bean in my generic code examples in blogs or forum/Q&A answers, but in real world you should avoid that.

FooManagedBean is a poor name, it's not only too long and ugly, but technically, a managed bean is an instance of a backing bean which is managed by some framework (JSF in this case). In JSF, the class definition itself is really a backing bean, not a managed bean. So a FooBackingBean is technically more correct, but it's still too long and the Bean part is still itchy.

FooBB and FooMB are not clear enough and those abbreviations "BB" and "MB" are unlike e.g. "EJB" and "JPA" nowhere mentioned in the official Java EE documents. This convention should be avoided.

Left behind the Foo, FooBacking, FooManager and FooController. In large projects, I personally tend to use "Manager" for session and application scoped beans which are not tied to any input forms and "Backing" for request and view scoped beans which are tied to input forms. Or if you have a relatively small project, then you could use "Controller" for all beans or even leave it entirely out.

In any way, this is a pretty subjective question which can hardly be answered objectively with The One And Correct answer. It really doesn't matter that much to me or anyone else what you makes of it, as long as you're consistent with it throughout the entire project. Consistency is next to self-document-ability a very important aspect in a project.

Back to top

Managed bean scopes

JSF2 offers six predefinied @ManagedBean scopes. Their lifetime and use are described in detail below:

  • @RequestScoped: a bean in this scope lives as long as the HTTP request-response lives. It get created upon a HTTP request and get destroyed when the HTTP response associated with the HTTP request is finished (this also applies to ajax requests!). JSF stores the bean as an attribute of HttpServletRequest with the managed bean name as key. It is also available by ExternalContext#getRequestMap(). Use this scope for pure request-scoped data. For example, plain vanilla GET requests which should present some dynamic data to the enduser depending on the parameters. You can also use this scope for simple non-ajax forms which do not require any model state during processing.
  • @ViewScoped: a bean in this scope lives as long as you're interacting with the same JSF view in the browser window/tab. It get created upon a HTTP request and get destroyed once you postback to a different view. It doesn't immediately get destroyed when you leave/close the view by a GET request, but it is not accessible the usual way anymore. JSF stores the bean in the UIViewRoot#getViewMap() with the managed bean name as key, which is in turn stored in the session. You need to return null or void from action (listener) methods to keep the bean alive. Use this scope for more complex forms which use ajax, data tables and/or several rendered/disabled attributes whose state needs to be retained in the subsequent requests within the same browser window/tab (view).
  • @SessionScoped: a bean in this scope lives as long as the HTTP session lives. It get created upon the first HTTP request involving this bean in the session and get destroyed when the HTTP session is invalidated (or when you manually remove the bean from the session map). JSF stores the bean as an attribute of HttpSession with the managed bean name as key. It is also available by ExternalContext#getSessionMap(). Use this scope for pure session-scoped data which can safely be shared among all browser windows/tabs (views) within the same session. For example, the logged-in user, the user preferences such as user-specific settings and the chosen language/locale, etc.
  • @ApplicationScoped: a bean in this scope lives as long as the web application lives. It get created upon the first HTTP request involving this bean in the application (or when the web application starts up and the eager=true attribute is set in @ManagedBean) and get destroyed when the web application shuts down (or when you manually remove the bean from the application map). JSF stores the bean as an attribute of the ServletContext with the managed bean name as key. It is also available by ExternalContext#getApplicationMap(). Use this scope for pure application-scoped data which can safely be shared among all sessions. For example, constants such as country codes, static dropdown values, web application specific settings, etc.
  • @NoneScoped: a bean in this scope lives as long as a single EL evaluation. It get created upon an EL evaluation and get destroyed immediately after the EL evaluation. JSF does not store the bean anywhere. So if you have for example three #{bean.someProperty} expressions in your view, then the bean get effectively created three times. Use this scope for a data bean which is purely supposed to be injected in another bean of a definied scope. The injected bean will then live as long as the acceptor bean.
  • @CustomScoped: a bean in this scope lives as long as the bean's entry in the custom Map which is created for this scope lives. You need to create and prepare this Map yourself in a broader scope, for example the session scope. You need to control the removal of the bean from the Map yourself. Use this scope if no one of the other scopes suits the requirement, for example a conservation scope which spans across multiple views.

Choose the right scope for the data the bean holds! Abusing an application scoped bean for session/view/request scoped data would make it to be shared among all users, so anyone else can see each other's data which is just plain wrong. Abusing a session scoped bean for view/request scoped data would make it to be shared among all tabs/windows in a single browser session, so the enduser may experience inconsitenties when interacting with every view after switching between tabs which is bad for user experience. Abusing a request scoped bean for view scoped data would make view scoped data to be reinitialized to default on every single (ajax) postback, causing possibly non-working forms. Abusing a view scoped bean for request scoped data doesn't affect the client, but it unnecessarily occupies server memory.

If the bean contains a mix of for example request-scoped and session-scoped data, then you should really split the beans in two different scoped beans. They can interact with each other by @ManagedProperty. See also the next chapter.

Back to top

Injecting managed beans in each other

You can use @ManagedProperty to inject among others @ManagedBean instances in each other. This is particularly useful if you have a request or view scoped bean associated with a page/form and would like to have instant access to a session or application scoped bean. For example, to get the currently logged-in user which is hold in a session scoped managed bean so that you can perform actions based on the currently logged-in user.

Here's the session scoped one:

package com.example.controller;

import java.io.Serializable;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;

@ManagedBean
@SessionScoped
public class ActiveUser implements Serializable {

    // ...

}

Here's the view scoped one:

package com.example.controller;

import java.io.Serializable;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.ViewScoped;

@ManagedBean
@ViewScoped
public class Products implements Serializable {

    // Properties ---------------------------------------------------------------------------------

    @ManagedProperty("#{activeUser}")
    private ActiveUser activeUser;

    // Init ---------------------------------------------------------------------------------------

    @PostConstruct
    public void init() {
        // You can do here your initialization thing based on managed properties, if necessary.
    }

    // Getters/setters ----------------------------------------------------------------------------

    public void setActiveUser(ActiveUser activeUser) {
        this.activeUser = activeUser;
    }

    // ...

}

Note that a getter is not required in this particular case.

Also noted should be that you can't access any injected dependencies in the constructor of the bean yet. It is not possible to set/inject instance variables if the instance does not exist yet. The instance exists only if the constructor is finished. The earliest point to access an injected dependency is a @PostConstruct annotated method. Such a method is for demonstration purposes also shown in the above example. The method name init() is by the way fully free to your choice. If you don't need such a method, then you can just omit it.

Back to top

Injecting request parameters in a view scoped bean

You can only inject a managed property of the same or a broader scope. So for example injecting request parameters as a managed property in a view scoped bean is (unfortunately) not going to work.

Following will not work:

package com.example.controller;

import java.io.Serializable;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.ViewScoped;

@ManagedBean
@ViewScoped
public class Bean implements Serializable {

    // Properties ---------------------------------------------------------------------------------

    @ManagedProperty("#{param.foo}")
    private String foo;

    // Getters/setters ----------------------------------------------------------------------------

    public void setFoo(String foo) {
        this.foo = foo;
    }

    // ...

}

This will fail with the following error message:

Unable to create managed bean bean. The following problems were found: - The scope of the object referenced by expression #{param.foo}, request, is shorter than the referring managed beans (bean) scope of view

To set request parameters in a view scoped bean, you would normally use <f:viewParam> tag as outlined in the chapter Processing GET request parameters. But it is possible to get them from the request parameter map during bean's (post)construction yourself.


    // Properties ---------------------------------------------------------------------------------

    private String foo;

    // Init ---------------------------------------------------------------------------------------

    @PostConstruct
    public void init() {
        FacesContext facesContext = FacesContext.getCurrentInstance();
        this.foo = facesContext.getExternalContext().getRequestParameterMap().get(foo);
    }

Back to top

@ViewScoped fails in tag handlers (update: fixed since Mojarra 2.1.18!)

When you bind an attribute of a tag handler by an EL value expression to a view scoped bean, then it will create a brand new view scoped instance upon every request, even though it's a postback to the same view. This is a chicken-egg issue as stated in JSF issue 1492 which is fixed in JSF 2.2 and for Mojarra 2.1 backported in version 2.1.18. Simply put, JSF needs to restore the partial view in order to get the view state (and all view scoped beans) back. However, tag handlers runs during view build/restore time when JSF is about to construct the component tree. So they will run first and not be aware about any beans available in the view scope. When restoring the view is finished, the original view scoped beans are found and will be put back in the view scope. However, all EL value expressions of the tag handlers have already obtained the evaluated value of a completely different view scoped bean instance beforehand!

Following is an overview of all tag handlers:

If you really need to bind a tag handler attribute by EL to a view scoped bean, such as


    <ui:include src="#{viewScopedBean.includeFileName}.xhtml" />

Then you need to turn off the partial state saving by the following context parameter in web.xml to get it to work properly:


    <context-param>
        <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
        <param-value>false</param-value>
    </context-param>

Globally disabling the partial state saving has however the disadvantage that the view state size will grow in size. So if you're using server side state saving method, then the server's memory usage will increase, or if you're using client side state saving method, then the network bandwidth usage will increase. Basically, you get the same view state information as it was in JSF 1.x. If possible, you can also just disable the partial state saving on a per-view basis by the following context parameter in web.xml:


    <context-param>
        <param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
        <param-value>/some.xhtml,/other.xhtml</param-value>
    </context-param>

It accepts a comma separated string of all view IDs for which the partial state saving should be disabled. If you do not want to disable it in any way, then you should really replace all EL usage in tag handlers by normal JSF components. Here's an overview of all tag handlers and the alternative approaches:

  • <c:choose>: use rendered attribute instead
  • <c:forEach>: use <ui:repeat> component instead
  • <c:if>: use rendered attribute instead
  • <c:set>: use <ui:param>, <f:viewParam>, @ManagedProperty or @PostConstruct instead
  • <f:actionListener>: use actionListener attribute instead
  • <f:convertXxx> like <f:convertNumber>: use converter attribute or <f:converter> instead
  • <f:facet>: sorry, no alternative, just do not use EL on any of its attributes
  • <f:validateXxx> like <f:validateLongRange>: use validator attribute or <f:validator> instead
  • <f:valueChangeListener>: use valueChangeListener attribute instead
  • <ui:decorate>: sorry, no alternative, just do not use EL on any of its attributes
  • <ui:composition>: sorry, no alternative, just do not use EL on any of its attributes
  • <ui:include>: use a bunch of <ui:fragment rendered> components with each a static <ui:include>
  • any custom tag file: make it a fullworthy JSF UIComponent instead

Here is an overview of stackoverflow.com questions and answers related to this:

Back to top

Implicit navigation

Ones who have worked with JSF 1.x navigation cases probably know what a hell of maintenance pain they can cause. Although, after all, in properly designed JSF web application their use should have been very minimal. POST form submits should navigate to the same page as the form and any results should be conditionally rendered on the very same page. In other words, the action methods should return an empty string, or null, or void anyway. Page-to-page navigation should take place by pure GET links, not by command links. This all is much better for user experience and SEO.

However, now JSF2 comes with two new components <h:link> and <h:button> which represents a pure GET link and button which both support the outcome attribute representing the navigation case outcome, the new implicit navigation support is more than welcome. You just have to specify the view ID (basically, just the filename and the folder path, if any) and JSF will take care about prefixing and/or suffixing the proper context path and FacesServlet mapping on the generated link and button in the HTML.

For example, the following view


    <h:link value="Home" outcome="home" />
    <h:link value="FAQ" outcome="faq" />
    <h:link value="Contact" outcome="contact" />

will generate the following HTML


    <a href="/contextname/home.xhtml">Home</a>
    <a href="/contextname/faq.xhtml">FAQ</a>
    <a href="/contextname/contact.xhtml">Contact</a>

Back to top

Implicit EL objects

JSF2 EL comes with a bunch of implicit EL objects which you can use in the view next to the managed beans. It are the following:

Particularly the #{component} one is interesting. It's like this in Java (and JavaScript) code. Below is an usage example:


    <h:inputText value="#{bean.value}" styleClass="#{component.valid ? '' : 'error'}" />

The #{component} of a <h:inputText> component refers to an instance of UIInput class which in turn has an isValid() method. So when you submit the form and a validation error occurs on the particular component, then the #{component.valid} will evaluate false which will then set the error class on the input. This allows you to easily style invalid inputs!


.error {
    background: #fee;
}

The #{resource} is primarily intented to be used in CSS stylesheets to locate background images as a JSF resource. Below is an usage example, assuming that the image file is identified by the resource library "layout" and the resource name "images/foo.png":


.someClass {
    background-image: url("#{resource['layout:images/foo.png']}");
}

Note that the CSS stylesheet itself should be included by <h:outputStylesheet>, otherwise EL in the CSS stylesheet won't be resolved.

Back to top

Implicit output text

Since JSF 2.0 / Facelets, it's possible to inline EL in template text without the need to wrap it in a <h:outputText>. This makes the source code better readable. Even more, Facelets will implicitly escape any HTML as well, like as in a real <h:outputText>.


    <p>Welcome, #{activeUser.name}!</p>

Only whenever you'd like to disable escaping using escape="false", or would like to assign id, styleClass, onclick, etc programmatically, then you still need <h:outputText>.

Back to top

Normal (synchronous) POST form

This is how a Facelet file with a normal POST form look like without any JSF2 ajax fanciness. Such a form would work perfectly fine in JSF1. We'll use this form as a kickoff to add JSF2 ajax fanciness in the following few chapters.

<!DOCTYPE html>
<html lang="en"
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets">
    <h:head>
        <title>Page Title</title>
    </h:head>
    <h:body>
        <h:form id="form">
            <h:panelGrid columns="3">
                <h:outputLabel for="input1" value="Input 1" />
                <h:inputText id="input1" value="#{bean.input1}" required="true" />
                <h:message id="input1message" for="input1" />

                <h:outputLabel for="input2" value="Input 2" />
                <h:inputText id="input2" value="#{bean.input2}" required="true" />
                <h:message id="input2message" for="input2" />

                <h:panelGroup />
                <h:commandButton value="Submit" action="#{bean.submit}" />
                <h:messages id="messages" globalOnly="true" layout="table" />        
            </h:panelGrid>
        </h:form>
    </h:body>
</html>

Some notes to the HTML/CSS purists:

  • Yes, a tableless form with a shitload of CSS would semantically have been more correct, but that's beyond the scope of this tutorial, we teach JSF, not CSS.
  • Yes, a HTML5 doctype is perfectly fine. Long story short, read this: Is it possible to use JSF/Facelets with HTML4/5?

Here's how the appropriate backing bean can look like:

package com.example.controller;

import javax.faces.application.FacesMessage;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
import javax.faces.context.FacesContext;

@ManagedBean
@RequestScoped
public class Bean {

    // Properties ---------------------------------------------------------------------------------

    private String input1;
    private String input2;
    
    // Actions ------------------------------------------------------------------------------------

    public void submit() {
        String message = String.format("Submitted: input1=%s, input2=%s", input1, input2);
        FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(message));
    }

    // Getters/setters ----------------------------------------------------------------------------

    public String getInput1() {
        return input1;
    }

    public void setInput1(String input1) {
        this.input1 = input1;
    }

    public String getInput2() {
        return input2;
    }

    public void setInput2(String input2) {
        this.input2 = input2;
    }

}
Back to top

Ajax (asynchronous) POST form

Turning a normal form into an ajax form is a matter of adding <f:ajax> to the UICommand component.


    <h:commandButton value="Submit" action="#{bean.submit}">
        <f:ajax execute="@form" render="@form" />
    </h:commandButton>

This requires that you're using <h:head> instead of <head>, otherwise the JSF-bundled Ajax helper JavaScript file won't be auto-included! When you run JSF with project stage set to "Development" by the following context parameter in web.xml,


    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>

then you would be noticed about this mistake by the following development error message:

· One or more resources have the target of 'head', but no 'head' component has been defined within the view.

Coming back to the JSF2 <f:ajax> tag:

The <f:ajax>'s execute attribute defaults to @this (which is in this particular case the sole UICommand component itself). So input values won't be submitted. You need to explicitly specify execute="@form" to submit the whole form. Or when you want to submit specific input components only, such as the first one, then use execute="@this input1". Yes, it's space separated (PrimeFaces for example also supports comma separation, but JSF2 thus not). Using @this is mandatory in order to let the button's action to execute anyway.

The <f:ajax>'s render attribute defaults to @none. You would like to render the entire form, so that validation messages will show up. You need to explicitly specify render="@form" then. Alternatively, maybe to save bandwidth, you can also specify to render only the message components. In this case, use render="input1message input2message messages". This may however end up to be cumbersome and hard-to-maintain.

The <f:ajax> has also an event attribute. The default value depends on the enclosing component. In case of UICommand components this defaults to event="action" which is perfectly fine to submit a form. JSF will then take care that the right HTML DOM event is been used to hook on an action, which is "click" in case of a standard command button and link.

Back to top

Ajax validation

This is a matter of adding <f:ajax> to the UIInput component with a render ID which points to the associated message component(s).


    <h:outputLabel for="input1" value="Input 1" />
    <h:inputText id="input1" value="#{bean.input1}" required="true">
        <f:ajax event="blur" render="input1message" />
    </h:inputText>
    <h:message id="input1message" for="input1" />

    <h:outputLabel for="input2" value="Input 2" />
    <h:inputText id="input2" value="#{bean.input2}" required="true">
        <f:ajax event="blur" render="input2message" />
    </h:inputText>
    <h:message id="input2message" for="input2" />

    <h:panelGroup />
    <h:commandButton value="Submit" action="#{bean.submit}">
        <f:ajax execute="@form" render="input1message input2message messages" />
    </h:commandButton>
    <h:messages id="messages" globalOnly="true" layout="table" />        

The <f:ajax>'s event attribute defaults in UIInput components to event="valueChange". JSF will then take care that the right HTML DOM event is been used to hook on a value change, which is "change" in case of text inputs and dropdowns and which is "click" in case of checkboxes and radiobuttons. However, in case of text inputs, when you tab along the required fields without entering a value, then the change event won't be fired. This may be affordable in some cases, but for the case that you would like to validate the text input immediately when the user leaves the field, then rather use event="blur".

Note that the <f:ajax>'s render attribute of the UICommand component in the above example has been changed to render the message components only. You can also use render="@form" here. Both approaches are equally fine. It's a matter of taste and maintainability.

The managed bean #{bean} can be placed in the request scope for such a form. But, with a big BUT, a request scoped managed bean will be recreated on every ajax request! You would like to use a view scoped managed bean instead. It'll live as long as you're firing ajax requests from the same view on and the regular action methods returns all null or void. Once a managed bean action method returns a valid navigation case outcome, even though it's to the same view, the view scoped managed bean will be garbaged and recreated.

package com.example.controller;

import java.io.Serializable;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;

@ManagedBean
@ViewScoped
public class Bean implements Serializable {

    // ...

}
Back to top

Ajax rendering of content outside form

Render IDs are resolved relative to the parent UINamingContainer component. Examples of UINamingContainer components are <h:form>, <h:dataTable>, <ui:repeat>, etc. It are those components which prepends the client ID of their children with its own client ID.

Following will not work:


    <h:form id="form">
        <h:commandButton value="Submit">
            <f:ajax render="result" />
        </h:commandButton>
    </h:form>
    <h:outputText id="result" value="#{bean.result}" />

Some JSF implementations/libraries would immediately show an error for this, either as a HTTP 500 error or some warning in the server log. Mojarra for example would throw an exception with a message like this (the j_idt6 is in this particular case just the autogenerated ID of the command button):

<f:ajax> contains an unknown id 'result' - cannot locate it in the context of the component j_idt6

If you prefix render ID with ":" then it's resolved relative to the view root. It becomes the absolute render ID.

Following will work:


    <h:form id="form">
        <h:commandButton value="Submit">
            <f:ajax render=":result" />
        </h:commandButton>
    </h:form>
    <h:outputText id="result" value="#{bean.result}" />

The absolute render ID needs to be the full client ID prefixed with ":". So if the render target is by itself nested in another UINamingContainer component, then you need to give it a fixed ID and include its ID as well.


    <h:form id="form">
        <h:commandButton value="Submit">
            <f:ajax render=":otherform:result" />
        </h:commandButton>
    </h:form>
    <h:form id="otherform">
        <h:outputText id="result" value="#{bean.result}" />
    </h:form>

An easy way to check for the right render ID is to check the client ID of the JSF-generated HTML element. Open the page in a webbrowser, rightclick and choose View Source. That's the JSF-generated HTML output. You need to locate the HTML element which has been generated by the JSF component in question. In case of a <h:outputText id="result"> which is been enclosed in a <h:form id="otherform"> it'll look like the following:


    <span id="otherform:result"></span>

You need to grab exactly that client ID and then prefix with ":" for the absolute render ID.

Back to top

Ajax rendering of content which contains another form

When you ajax render some content which in turn contains another form, then it won't work flawlessly because the other form would lose its view state. The view state is stored in a hidden input field with the name javax.faces.ViewState. The JSF JavaScript library is supposed to re-add the hidden field after ajax render.

Following will not work:


    <h:panelGroup id="firstPanel">
        <h:form id="firstForm">
            <h:outputLabel for="input" value="First form input" />
            <h:inputText id="input" value="#{bean1.input}" required="true" />
            <h:commandButton value="Submit form" action="#{bean1.submit}">
                <f:ajax execute="@form" render="@form :secondPanel :messages" />
            </h:commandButton>
            <h:message for="input" />
        </h:form>
    </h:panelGroup>
    <h:panelGroup id="secondPanel">
        <h:form id="secondForm">
            <h:outputLabel for="input" value="Second form input" />
            <h:inputText id="input" value="#{bean2.input}" required="true" />
            <h:commandButton value="Submit other form" action="#{bean2.submit}">
                <f:ajax execute="@form" render="@form :firstPanel :messages" />
            </h:commandButton>
            <h:message for="input" />
        </h:form>
    </h:panelGroup>
    <h:messages id="messages" globalOnly="true" layout="table" />

Now, leave the fields empty and click the submit button of the first form. A validation error shows for the first input. This is fine. Now click the submit button of the second form with the fields still empty. You'd expect that a validation error shows for the second input. But it does not show up! Only the validation error of the first form disappears. When you would have entered the field, the managed bean action method of the second form would not be invoked. You need to click the button twice to get it to work. Repeat then the same on the first form and so on. You need to enter the field and click the button once again everytime to get the form to be submitted.

What is happening here is that the javax.faces.ViewState hidden input field is not added to the other form. This is an issue in the JSF JavaScript library and already acknowledged by the JSF spec guys and is currently been scheduled to be fixed in 2.3: JSF spec issue 790. Both Mojarra and MyFaces exposed the same issue, however MyFaces has fixed it rather quickly while Mojarra 2.2 still hasn't fixed. To get it to work you would need to explicitly add the client ID of the other form in the <f:ajax> render.


    <h:panelGroup id="firstPanel">
        <h:form id="firstForm">
            <h:outputLabel for="input" value="First form input" />
            <h:inputText id="input" value="#{bean1.input}" required="true" />
            <h:commandButton value="Submit form" action="#{bean1.submit}">
                <f:ajax execute="@form" render="@form :secondPanel :secondForm :messages" />
            </h:commandButton>
            <h:message for="input" />
        </h:form>
    </h:panelGroup>
    <h:panelGroup id="secondPanel">
        <h:form id="secondForm">
            <h:outputLabel for="input" value="Second form input" />
            <h:inputText id="input" value="#{bean2.input}" required="true" />
            <h:commandButton value="Submit other form" action="#{bean2.submit}">
                <f:ajax execute="@form" render="@form :firstPanel :firstForm :messages" />
            </h:commandButton>
            <h:message for="input" />
        </h:form>
    </h:panelGroup>
    <h:messages id="messages" globalOnly="true" layout="table" />

No, this does not cause an overhead in the JSF ajax response. Since the component referenced by :secondForm is already a child of the component referenced by :secondPanel, this will just be skipped in the JSF ajax response. But the JSF JavaScript library will now add the mandatory javax.faces.ViewState hidden input field to the second form.

Back to top

Automatically fix missing JSF view state after ajax rendering

An alternative to explicitly specifying the forms in ajax render is to include this piece of JavaScript which should automatically detect any missing javax.faces.ViewState hidden input fields and automatically append them:

jsf.ajax.addOnEvent(function(data) {
    if (data.status == "success") {
        var viewState = getViewState(data.responseXML);

        for (var i = 0; i < document.forms.length; i++) {
            var form = document.forms[i];

            if (form.method == "post" && !hasViewState(form)) {
                createViewState(form, viewState);
            }
        }
    }
});

function getViewState(responseXML) {
    var updates = responseXML.getElementsByTagName("update");

    for (var i = 0; i < updates.length; i++) {
        if (updates[i].getAttribute("id").match(/^([\w]+:)?javax\.faces\.ViewState(:[0-9]+)?$/)) {
            return updates[i].firstChild.nodeValue;
        }
    }

    return null;
}

function hasViewState(form) {
    for (var i = 0; i < form.elements.length; i++) {
        if (form.elements[i].name == "javax.faces.ViewState") {
            return true;
        }
    }

    return false;
}

function createViewState(form, viewState) {
    var hidden;
    
    try {
        hidden = document.createElement("<input name='javax.faces.ViewState'>"); // IE6-8.
    } catch(e) {
        hidden = document.createElement("input");
        hidden.setAttribute("name", "javax.faces.ViewState");
    }

    hidden.setAttribute("type", "hidden");
    hidden.setAttribute("value", viewState);
    hidden.setAttribute("autocomplete", "off");
    form.appendChild(hidden);
}

Note that when you're using PrimeFaces and its own ajax components like <p:commandButton> and so on, then you don't need the above workaround; they have already fixed this matter in their own core ajax engine.

Back to top

Ajax rendering of content which is by itself conditionally rendered

Ajax rendering takes place fully at the client side and expects the to-be-updated HTML element to be already in the JSF-generated HTML output.

Following will not work when #{bean.renderResult} defaults to false:


    <h:form id="form">
        <h:commandButton value="Submit" action="#{bean.toggleRenderResult}">
            <f:ajax render=":result" />
        </h:commandButton>
    </h:form>
    <h:outputText id="result" value="#{bean.result}" rendered="#{bean.renderResult}" />

You need to ensure that the render ID points to a component which is already present in the JSF-generated HTML output.

Following will work:


    <h:form id="form">
        <h:commandButton value="Submit" action="#{bean.toggleRenderResult}">
            <f:ajax render=":result" />
        </h:commandButton>
    </h:form>
    <h:panelGroup id="result">
        <h:outputText value="#{bean.result}" rendered="#{bean.renderResult}" />
    </h:panelGroup>

Back to top

Passing POST action method arguments

Since EL 2.2, which is maintained as part of Servlet 3.0 / JSP 2.2 (thus, Tomcat 7, Glassfish 3, JBoss AS 6, etc or newer), it is possible to pass fullworthy objects as JSF action method arguments.


    <h:form>
        <h:dataTable value="#{bean.users}" var="user">
            <h:column>#{user.id}</h:column>
            <h:column>#{user.name}</h:column>
            <h:column>#{user.email}</h:column>
            <h:column><h:commandButton value="Edit" action="#{bean.edit(user)}" /></h:column>
        </h:dataTable>
    </h:form>

In combination with this bean method:


    public void edit(User user) {
        this.user = user;
        this.edit = true;
    }

See also the article Benefits and pitfalls of @ViewScoped - Really simple CRUD, now without DataModel

Another interesting use case is the following:


    <h:form>
        <f:ajax render=":include">
            <h:commandLink value="Home" action="#{menu.setPage('home')}" /><br />
            <h:commandLink value="FAQ" action="#{menu.setPage('faq')}" /><br />
            <h:commandLink value="Contact" action="#{menu.setPage('contact')}" /><br />
        </f:ajax>
    </h:form>
    <h:panelGroup id="include">
        <ui:include src="#{menu.page}.xhtml" />
    </h:panelGroup>

Note that you should specify the full setter method name in action attribute! Also note that this approach fails when the include page contains a form.

When you're still targeting an old Servlet 2.5 / JSP 2.1 container (e.g., Tomcat 6, Glassfish 2, JBoss AS 5, etc), then you can always install JBoss EL to add the same enhancements for EL 2.1. Just grab and drop jboss-el-2.0.0.GA.jar in your webapp's /WEB-INF/lib folder and add the following (Mojarra-specific!) context parameter to your web.xml:


    <context-param>
        <param-name>com.sun.faces.expressionFactory</param-name>
        <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
    </context-param>

Back to top

Processing GET request parameters

JSF2 offers the new <f:viewParam> tag to set GET request parameters in a managed bean. Back in old JSF 1.x you could also set them as a managed property in faces-config.xml, however that works on request scoped beans only and it does not allow for fine-grained conversion and validation. The new @ManagedProperty annotation does nothing different. The <f:viewParam> works on view scoped beans as well (and also on session and application scoped ones, but the benefit is questionable). It allows for declarative conversion and validation with <f:converter> and <f:validator> and even a <h:message> can be attached to it.

Let's first start with creating GET links with request parameters in a list:


    <ul>
        <ui:repeat value="#{bean.users}" var="user">
            <li>
                <h:link value="View details of #{user.name}" outcome="user">
                    <f:param name="id" value="#{user.id}" />
                </h:link>
            </li>
        </ui:repeat>
    </ul>

The <h:link> will end up something like the following in the HTML:


    <ul>
        <li><a href="/contextname/user.xhtml?id=123">View details of BalusC</a></li>
        <li><a href="/contextname/user.xhtml?id=456">View details of John Doe</a></li>
        <li><a href="/contextname/user.xhtml?id=789">View details of Nobody</a></li>
    </ul>

In the user.xhtml file, you can at its simplest use <f:viewParam> to set the id as a property of the managed bean and use <f:event type="preRenderView"> to trigger a managed bean method whenever all view parameters have been set:


    <f:metadata>
        <f:viewParam name="id" value="#{bean.userId}" />
        <f:event type="preRenderView" listener="#{bean.init}" />
    </f:metadata>
    <h:head>
        <title>User Details</title>
    </h:head>
    <h:body>
        <h:messages />
        <h:panelGrid columns="2" rendered="#{not empty bean.user}">
            <h:outputText value="ID" />
            <h:outputText value="#{bean.user.id}" />

            <h:outputText value="Name" />
            <h:outputText value="#{bean.user.name}" />

            <h:outputText value="Email" />
            <h:outputText value="#{bean.user.email}" />
        </h:panelGrid>
        <h:link value="Back to all users" outcome="users" />
    </h:body>

Note: as per the upcoming JSF 2.2, the <f:event type="preRenderView"> should be replaced by a more self-documenting <f:viewAction>, see also this article of my fellow Arjan Tijms: What's new in JSF 2.2?


        <f:viewAction action="#{bean.init}" />

Here's how the backing bean can look like:

package com.example.controller;

import java.io.Serializable;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;

import com.example.business.UserService;
import com.example.model.User;

@ManagedBean
@ViewScoped
public class Bean implements Serializable {

    // Properties ---------------------------------------------------------------------------------

    private Long userId;
    private User user;

    // Services -----------------------------------------------------------------------------------

    @EJB
    private UserService userService;
    
    // Actions ------------------------------------------------------------------------------------

    public void init() {
        if (userId == null) {
            String message = "Bad request. Please use a link from within the system.";
            FacesContext.getCurrentInstance().addMessage(null, 
                new FacesMessage(FacesMessage.SEVERITY_ERROR, message, null));
            return;
        }

        user = userService.find(userId);

        if (user == null) {
            String message = "Bad request. Unknown user.";
            FacesContext.getCurrentInstance().addMessage(null, 
                new FacesMessage(FacesMessage.SEVERITY_ERROR, message, null));
        }
    }

    // Getters/setters ----------------------------------------------------------------------------

    public Long getUserId() {
        return userId;
    }

    public void setUserId(Long userId) {
        this.userId = userId;
    }

    public User getUser() {
        return user;
    }
    
}

Note that there's some unnecessary boilerplate code in the backing bean. Ultimately, you would like to end up with only the User property. Check the next chapter.

Back to top

Converting and validating GET request parameters

You see, in the previous chapter there's some boilerplate in the init() which does the conversion (and essentially also validation). This can be improved by extracting the conversion from the backing bean into a fullworthy and reuseable Converter class as follows:

package com.example.converter;

import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.ConverterException;

import com.example.business.UserService;
import com.example.model.User;

@ManagedBean
@RequestScoped // Can also be @ApplicationScoped if the Converter is entirely stateless.
public class UserConverter implements Converter {

    // Services -----------------------------------------------------------------------------------

    @EJB
    private UserService userService;

    // Actions ------------------------------------------------------------------------------------

    @Override
    public String getAsString(FacesContext context, UIComponent component, Object value) {
        if (!(value instanceof User) || ((User) value).getId() == null) {
            return null;
        }

        return String.valueOf(((User) value).getId());
    }

    @Override
    public Object getAsObject(FacesContext context, UIComponent component, String value) {
        if (value == null || !value.matches("\\d+")) {
            return null;
        }

        User user = userService.find(Long.valueOf(value));

        if (user == null) {
            throw new ConverterException(new FacesMessage("Unknown user ID: " + value));
        }

        return user;
    }

}

Yes, it's a @ManagedBean instead of @FacesConverter! How awkward, but it's not possible to inject an @EJB inside a @FacesConverter in order to do the DB interaction job. The same problem manifests when you use the CDI @Inject to inject a property, you'd need to use @Named instead of @FacesConverter. The Java EE/JSF/CDI guys are working on that for the future JSF 2.2 version, see also JSF spec issue 763. Update: unfortunately, it didn't made into JSF 2.2. It has been postponed to JSF 2.3. JSF utility library OmniFaces will have a CDI compatible @FacesConverter/FacesValidator in version 1.6.

If you really need to have it to be a @FacesConverter (in order to utilize the forClass attribute, for example), then you can always manually grab the EJB from JNDI. See also the next chapter.

Now, you can specify the above converter in the converter attribute as follows and validate it as required as well. The appropriate error messages can be specified by converterMessage and requiredMessage respectively. Please note that you need to specify the converter in the view using converter="#{userConverter}" instead of converter="userConverter" because it's @ManagedBean instead of @FacesConverter.


    <f:metadata>
        <f:viewParam name="id" value="#{bean.user}"
            converter="#{userConverter}" converterMessage="Bad request. Unknown user."
            required="true" requiredMessage="Bad request. Please use a link from within the system."
        />
    </f:metadata>

Now we can make the backing bean more terse:


    // Properties ---------------------------------------------------------------------------------

    private User user;

    // Getters/setters ----------------------------------------------------------------------------

    public User getUser() {
        return user;
    }
    
    public void setUser(User user) {
        this.user = user;
    }

Back to top

Getting an EJB in @FacesConverter and @FacesValidator

There's a way to get an EJB in a @FacesConverter and @FacesValidator. You only have to manually lookup it from JNDI. First create some utility class which does the job. The below one assumes that EJBs are deployed in the WAR (as you would do in Java EE 6 Web Profile), for EARs you'd need to alter the EJB_CONTEXT to add the EJB module name:

package com.example.util;

import javax.naming.InitialContext;
import javax.naming.NamingException;

/**
 * Utility class for EJBs. There's a {@link #lookup(Class)} method which allows you to lookup the 
 * current instance of a given EJB class from the JNDI context. This utility class assumes that 
 * EJBs are deployed in the WAR as you would do in Java EE 6 Web Profile. For EARs, you'd need to
 * alter the <code>EJB_CONTEXT</code> to add the EJB module name or to add another lookup() method.
 */
public final class EJB {

    // Constants ----------------------------------------------------------------------------------

    private static final String EJB_CONTEXT;

    static {
        try {
            EJB_CONTEXT = "java:global/" + new InitialContext().lookup("java:app/AppName") + "/";
        } catch (NamingException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    // Constructors -------------------------------------------------------------------------------

    private EJB() {
        // Utility class, so hide default constructor.
    }

    // Helpers ------------------------------------------------------------------------------------

    /**
     * Lookup the current instance of the given EJB class from the JNDI context. If the given class
     * implements a local or remote interface, you must assign the return type to that interface to
     * prevent ClassCastException. No-interface EJB lookups can just be assigned to own type. E.g.
     * <li><code>IfaceEJB ifaceEJB = EJB.lookup(ConcreteEJB.class);</code>
     * <li><code>NoIfaceEJB noIfaceEJB = EJB.lookup(NoIfaceEJB.class);</code>
     * @param <T> The EJB type.
     * @param ejbClass The EJB class.
     * @return The instance of the given EJB class from the JNDI context.
     * @throws IllegalArgumentException If the given EJB class cannot be found in the JNDI context.
     */
    @SuppressWarnings("unchecked") // Because of forced cast on (T).
    public static <T> T lookup(Class<T> ejbClass) {
        String jndiName = EJB_CONTEXT + ejbClass.getSimpleName();

        try {
            // Do not use ejbClass.cast(). It will fail on local/remote interfaces.
            return (T) new InitialContext().lookup(jndiName);
        } catch (NamingException e) {
            throw new IllegalArgumentException(
                String.format("Cannot find EJB class %s in JNDI %s", ejbClass, jndiName), e);
        }
    }

}

Note that this works in a Java EE 6 container only! In Java EE 5 and before, there's no way to obtain the application name from JNDI. You would need to hardcode it yourself or provide it by some configuration file (e.g. properties or XML file) or as VM argument.

Now you can turn the UserConverter into a fullworthy @FacesConverter:

package com.example.converter;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.ConverterException;
import javax.faces.convert.FacesConverter;

import com.example.business.UserService;
import com.example.model.User;
import com.example.util.EJB;

@FacesConverter(forClass=User.class)
public class UserConverter implements Converter {

    // Services -----------------------------------------------------------------------------------

    private UserService userService = EJB.lookup(UserService.class);

    // ...
}

Thanks to the forClass attribute of the @FacesConverter, it will always be automatically invoked whenever a managed bean property of exactly the given type is to be converted. So, you can omit the converter attribute from the <f:viewParam>:


    <f:metadata>
        <f:viewParam name="id" value="#{bean.user}"
            converterMessage="Bad request. Unknown user."
            required="true" requiredMessage="Bad request. Please use a link from within the system."
        />
    </f:metadata>

63 comments:

kiwifrog said...

Great article as usual. Crystal clear and informative.
I was starting to miss your updates (no time to read StackOverflow).

Keep up the good work BalusC and thanks for sharing.

Oleg Varaksin said...

Great post, even for experienced JSF developers (in order to brush up existing knowledge). Many thanks for your blog!

Umoh said...

Dude, you're freaking awesome. I was literally Grinning and Shaking my head the whole Time. Its amazing how much I didn't know and How much stuff I was doing wrongly.
Where do you get all this information from?

Oleg Varaksin said...

One question yet. You have recommended to use static instead of dynamic one. With static includes we have a lot of blocks with rendered="true / false" and the component tree is very big. The big component tree is restored in the first JSF phase (not good). I prefer really dynamic includes. Do you know this post "Layouting and Dynamic Includes in Facelets"? - http://www.techbrainwave.com/?p=136&cpage=1 See last comments especially. What do you think about dynamic include on postback?

BalusC said...

@All: you're welcome :)

@Umoh: lot of practical experience and lot of reading/answering questions on Stackoverflow.

@Oleg: that article uses a session scoped bean. It will work without problems that way, but it get reflected on every browser window/tab and will thus result in unintuitive webapp behaviour (and bad user experience).

You really want a view scoped bean here, but it get reconstructed on every request! This is not immediately a problem for the include itself nor necessarily expensive, but this causes that any h:form which is placed inside the an include page other than the bean's default include page will not be found and not processed.

The workaround would be to put the h:form outside the ui:include and do not use the h:form inside an include page. But this still requires disabling the partial state saving.

If disabling the partial state saving is not an option due to memory issues, then you really need to use a bunch of static includes inside conditionally rendered UI components.

Oleg Varaksin said...

Thanks BalusC for your reply. I prefer session scoped bean for dynamic include. This is not a problem with browser tabs (ICEFaces has e.g. a special window scope). The problem is resource rendering. If you include new page fragments with new components, the head section gets not updated automatically. That means, CSS / JS files declared with @ResourceDependency in included components are not available in the head. We discissed that issue in PrimeFaces forum and I found a solution which should be proved yet.

I have another question regardinsg DOCTYPE for HTML5. You told us about using that in facelets. I have used until now XHTML 1.0 Transitional. What will happen if browser doesn't support HTML5? Is there a fallback? Is fallback Strict or Transitional mode? I have worries that JSF components of third libraries will not work smooth with DOCTYPE html in all browsers. PrimeFaces' showcase has e.g. XHTML 1.0 Transitional in facelets.

Thanks a lot in advance.

BalusC said...

@Oleg: using HTML5 doctype works fine in all browsers expect of IE6 which will render in quirks mode (which is just a layout issue, the functionailty will remain just fine). IE6 usage is however greatly decreasing last years.

Failure/fallback in browsers only applies whenever you're using HTML5 specific elements such as <input type="range">, <canvas>, etc. This does not apply to HTML4 elements. Standard JSF implementations does not have any HTML5 specific elements, so it should work just fine in all browsers. The same applies to component libraries. Only PrimeFaces 3 for example, has some HTML5 specific elements (e.g. file upload), but they gracefully degrades to HTML4 when the browser doesn't support it.

Oleg Varaksin said...

Hi,

Sure, I have understood. What I meant were pure widgets themself. I don't know, but some JS widgets used by PrimeFaces or wherever may expect HTML 4 Transitional to be able to use some CSS / HTML hacks. I'm sure if you would use Strict mode, some pages (layout etc.) could be broken. Therefore I asked about HTML5 DOCTYPE. But I think everything will be ok. Have you ever tried PrimeFaces with DOCTYPE html?

Thanks.

Lucas Theisen said...

You might want to add you solution to the circular managed bean reference using the setter of the parent to inject itself in the child. That was useful and would fit nicely in your Injecting managed beans in each other section.

smithh032772 said...

Very good read, thanks BalusC! After reading some of your other posts/answers either here or on stackoverflow.com, I changed my JSF managed beans from SessionScoped to ViewScoped, and I just realized after reading this post that I can reference other managed beans via UIViewRoot.getViewMap() instead of getExternalContext().getSessionMap(). I'm going to try this and/or the managed property way of injecting managed bean in another managed bean (within the same scope, of course).

Learning a lot from your BalusC. Thanks again!

Patrick said...

Hi BalusC, "This release of Mojarra is not known to work in Apache Tomcat or Jetty." is declared as the known issue since 2.1.1 till the latest 2.1.4. Wondering which version is workable for Tomcat (be it 6 or 7)?

BalusC said...

@Patrick: only 2.1.0 doesn't work on Tomcat/Jetty. 2.1.1 and newer works on Tomcat. I tell from experience.

Patrick said...

Haha, of course! I know you (your blog) since jsf 1. Just want to ensure it is the same mojarra that we are looking at, after all so many unfortune happen to jsf. Well, thanks for the prompt reply!

ethereal said...

Thanks for the information BalusC, I was interested to see your comment about mojarra 2.1.x having fixed the issues with glassfish code that were breaking tomcat. Thanks to you and the information here and here, I was able to get mojarra 2.1.4 running on tomcat 6.0.33, SWF 2.3.0, & Richfaces 4.0.0 :)

undermanager said...

@BalusC - I've lost count of the times I've been researching a JSF question or issue and your name pops up with a solution - thank you for so many great articles and answers!

I see in your article here (and maybe articles elsewhere) that you focus on Faces managed beans and scopes (for example, @ManagedBean and javax.faces.bean.SessionScoped, and so on). There is, of course, also the CDI/Weld world (for example, @Named and javax.enterprise.context.SessionScoped, and so on).

Do you have an opinion on when it makes sense to use one over the other? What factors are important in making this choice?

Srikanth said...

Great Post!!- Thanks @BalusC

Its my first month on JSF 2.0 and your blog is such an awesome place for a person like me, which gives better solution for implementing my use cases.

I have a question:
- once redirecting to next page, does f:metadata or the managedbean gets loaded first ?

if f:metadata gets prior loaded then:

...



here f:event making a call to lstnr method in bean(ManagedBean), then Bean gets instantiated ?


And which way do you suggest f:metadata or @PostConstruct or FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap()



Thanks in Adv.
Once again Appreciate your Blog !!

Rafael Ponte said...

Hi BalusC,

I believe you could use javax.faces.FULL_STATE_SAVING_VIEW_IDS context parameter rather than javax.faces.PARTIAL_STATE_SAVING=false to solving the @ViewScoped issues. Probably it's better than turning PARTIAL_STATE_SAVING off to entire application, right?

Fernando Miño said...

MyFaces 2.1 targets Servlet 2.5, and is compatible with tomcat 6

Caffé said...

Whenever I need something about Java I get involved in a lot of non-useful posts, and I get more and more confused, until I find one of your posts. Thanks, BalusC! I have developed an application in Java and have no other resources away from the internet. Thank you for your very honest and non-trivial posts.

real said...

Thanks for sharing info. I've wasted two days for looking info about ViewState and dynamic facelets includes. Now it works.

Unknown said...

@BalusC, excellent job. The section on "Ajax Rendering Of Content Which Is By Itself Conditionally Rendered" was exactly what I was trying to figure out.

My situation is that I have a textarea field that I want to be initially not rendered. I used the technique you described of putting it inside a panel group. When the text box is checked, the textarea appears! However, now my problem is that when the form is submitted, the property of the managed bean which is bound to that textarea does not get set to whatever the user entered in the textarea. What do I need to do to make this work?

BalusC said...

@Unknown: put the bean in the view scope. This way the bean lives as long as you're interacting with the same view (by returning null/void).

tcprogrammer said...

@BalusC, I thought of using view scope, except the application calls for a number of different pages that the user must visit to fill in all the properties of the bean. For that reason I need it in session scope. I found another solution to hide/unhide the component using java script which works for me in this case. But, I might have future cases where I really want to make an ajax call. Is there a way to do this with a session bean?

Carlos said...

I tried your solution to inject a CDI Bean using @Named in my Converter but it doesn't work. The converter cannot be found. Did I overlook something? I'm only using @Named in my Converter (without any other annotation)

Kiddo said...
This comment has been removed by the author.
Kiddo said...

I'd like to create a list and detail pages for CRUD app with common layout and hence, I use facelet template.

In the list page, I have a data table with a link that passes the id to the detail page using f:param name="id" value="object.id".

In the detail page, I'll put the "f:viewParam" within "f:metadata" and load the data using preRenderView event.

But, because I use facelet template, everything outside "ui:composition" is thrown away and thus, the preRenderView event will not be called.

How to get around this?

Thx

Jeancarlo Sott said...

Hi BalusC, greate article as always. I have a problem with data state. I have some menu items, they set the page (.xhtml) for a ui:include tag. The menu and the includes are working fine. The problem is when I change between menu items, the state (values) is not restored. Is this related to some of these STATE_SAVING props or is something to do with the right use of the components, like the use of ui:include ? I'm using the last primefaces and myfaces and the bean is session scoped.

Thank yout
Jeancarlo.

Traduce said...

How we can config web.xml when we are using the richfaces.Would you please show the example of richfaces in jsf 2.
->I have used glassfish 3.1
->Netbeans Id 6.9.1

i have tired to do with richfaces using in jsf2

- said...

"Here's an overview of all tag handlers and the alternative approaches:
...
f:convertXxx like f:convertNumber: use converter attribute or f:converter instead
...
f:validateXxx like f:validateLongRange: use validator attribute or f:validator instead"

Maybe I'm missing something, but AFAI can see, f:converter and f:validator are tag handlers too?

To get hold of a @ViewScoped bean inside my converter, I currently do FacesContext.getCurrentInstance().getApplication()
.evaluateExpressionGet(context, "#{" + beanName + "}", MyBean.class);

Is there a better way...?

Lukas Meier said...

i'm just informing myself about jsf 2, so forgive me if I'm wrong. In your code details you refer to #{bean.initUser} and in your class you have the method Bean#init() - I guess you are addressing the very same method.

Bauke Scholtz said...

@Lukas: sorry, that was a typo. I fixed it.

fernandofranzini said...

Great post Bauke!!I have a doubt.
I realized that in JSF 2, when filled with null fields are not rendered with rendering using the f: ajax or a4j: ajax. In fact nothing happens, getting the same previous value. You know me explain why and how the fields are rendered with empty when they are null?

Jacob said...

BalusC

I have followed and practiced many tutorials which you have posted on your blog. It is very simple and easy to understand.

Could it be possible for you to write an article on EJB as I would like to know how to use EJB in applications.

Thanks and regards

Ponic

Prashant Rathod said...
This comment has been removed by the author.
amer sohail said...

Thanks for full of information.
I have a question. I am using prime faces command button With ajax="true" to navigate from one page to another page. On navigated page i have to press button twice first time to make it work. After that all buttons work fine on first click. I know there is a bug in jsf 2.1 that second page's state is lost with ajax navigation but u mentioned that it was handled in primefaces but i am still having that issue. I am using primefaces 3.4. Moreover i want to use commandbutton with ajax in order to avoid any back button issue.

Jonathan Bispo said...

Very good. It help me a lot. Thanks for the article.

Kawu said...

What is the best scope of a CDI converter when the primary bean scope is view-scoped? I noticed I had annotated all converters with @Named + @RequestScoped, but I fear @Named + ViewScoped would create much less overhead. Is that true?

Jens Hartwig said...

Regarding "@ViewScoped fails in tag handlers": Shouldn't something like the following result in broken ViewScope?



Jens Hartwig said...

sorry, the tag were purged...

https://gist.github.com/4447802

Life has a twist said...

Hi,

I am facing the below problem:

on click of a button i am adding the details to a DB and returning the same. i return to the ssame page . i click on the hyperlink to retrieve the value i have just entered.

the value returned is null. Wat scope should be added. Pls help.

Thanks,
Poo

Chris Graham said...

Do you have/know a post that gives more information on this, specific to JSF, with rationale?:

> "POST form submits should navigate to the same page as the form and any results should be conditionally rendered on the very same page. In other words, the action methods should return an empty string, or null, or void anyway. Page-to-page navigation should take place by pure GET links, not by command links. This all is much better for user experience and SEO."

Are you suggesting that a web app simply avoid having clicks that both perform an action and bring the user to a different page?
This would rub our own usability-minded people the wrong way in terms of adding clicks to the workflow.

I have been thinking of posting-back pages as a prelude to any navigation, as good general practice.
This has been useful to me in eg. remembering selections made on List Page X before drilling into Item Detail Page Y, later to return to make more selections.

As well, it seems obvious for a Wizard, but perhaps that fits the definition of a special case.[

User experience issue-wise, I can understand the problem with the browser URL pointing to the "wrong" resource, destroying at least bookmarkability.
And making any Refresh attempt a re-do of a form post.

But this sort of thing is normally handled by forcing a redirect, when considered important enough?
Though I haven't tried this in JSF yet.

Are there additional issues, that I am not thinking of?

Sameet Kumar Bhole said...

i need a help i need to send the activation mail to the user what he has specified the email address in create user page . and that mail should contain a link with temporary password which should generate randomly and that link which contain my specified page .Please help me out

Koray said...

Hello,

Is this an Injection:

@EJB
private UserService userService;

Because it seems you do not initialize userService anywhere in the code?

Koray said...

Hello,

Is this an Injection:

@EJB
private UserService userService;

Because it seems you do not initialize userService anywhere in the code?

Kodlapaylas said...

Greate article for JSF ! Thanks!!

Salvo Isaja said...

Hi BalusC, thank you very much for your very valuable posts.
I'm doing some experimentation using only RequestScoped beans with transient views, to see if I can avoid the pitfalls of ViewScoped and client state saving. In the scenario you describe in "Ajax rendering of content outside form", it seems that Mojarra 2.1.23 does not add javax.faces.ViewState=stateless even if I name the form id.
Do you have any hints on that?

Java Guru said...

Hi BalusC, thank you very much for your very avaluable posts.One question though...

i have a custom converter as follows



How to add attribute to it, so that i can access that value?
In this case i wanted to scale/precesion....i know we can add <f:attribute and access that in my custom Converter class, but problem with this is, we need to acess with form name.....but i need generic one....

please through some light on this. thx

shahinur islam said...
This comment has been removed by the author.
shahinur islam said...

I am facing trouble like i have a main form and have some dynamically added form in main form with some action component. I have a “add” button in main form which will add and new object in list and on parent container it will render all sub forms and added another empty form for adding new record.
In my cases the following example its not working.

In my cases the following example its not working.

h:form id="mainForm"
h:panelGroup id="dummyBeanListContainer"
ui:repeat var="dummy" value="#{setupdummysBean.dummyLists}" varStatus="status"
h:form
h:inputText value="#{dummy.redeemFromUser.fullName}" id="searchInput" tabindex="#{tabIndexBean.index}" class="appreciation-input typeAheadField"
required="true" placeholder="Test" requiredMessage="humm" autocomplete="off"
f:ajax event="blur" listener="#{setupdummysBean.valueChanged()}" execute="@form""/f:ajax
/h:inputText
/h:form
/ui:repeat
/h:panelGroup
h:commandLink value="#{msg['dummyBean.action.add']}" actionListener="#{setupdummysBean.addEmptydummyBean()}" styleClass="icon-plus-sign"
f:ajax render=" dummyBeanListContainer "/f:ajax
/h:commandLink
/h:form

“/” means end tag as I could not post xml here.

any help is really appreciate.

Jay said...

Hi BalusC

I am a fan of your JSF articles every where on web. Can you please kindly suggest a solution ?

Due to a special case we use jdbc connection instead of connection pool. Ever logged in user will hold one and only DB connection at a time. If a logged in user close the browser instead of a proper logout, his DB connection get held till the idle timeout (15 mins) and he cannot login again immedietly within this 15 mins timeout.

Is there any way to close the user DB connection, if he closes the browser instead of logout ?

I use Primefaces / JSF2

Please kindly advice.

Thanks
Jayakumar

vantar said...

@BalusC
Can i use it - http://balusc.blogspot.com/2011/09/communication-in-jsf-20.html#ProcessingGETRequestParameters - to edit row from table in another view ?

Cause i have security problem.

For example I show to user filtered list of his own objects.
He would like to edit one of them. Navigation from table to edit form is done by GET param ?id=x. It works well.

But what if user place other id in URL and hits enter.
The form will be filled with the object from DB that he should not have access - cause it's not in his collection.

Do i have to check it in Converter if this object belongs to his collection (for example additional where clause in getById method?)

Maybe it's not strictly to JSF but i'm still learning and i would like to know how to make such scenario right :) maybe i should do redirect from table to form in some other way?

gwong thate said...

awesome article....,but i have a confusion , can i use ManageBeans like this :

@ManagedBean(name = "studentBBean")
@ViewScoped
public class StudentBBean {

@ManagedProperty(value = "#{collegeBBean}")
private CollegeBBean collegeBBean;
}


and In CollegeBBean.java

@ManagedBean(name = "CollegeBBean")
@ViewScoped
public class CollegeBBean {

@ManagedProperty(value = "#{studentBBean}")
private StudentBBean studentBBean;
}


Means in cyclic way

Rafael Ponte said...

Balusc,

Are <f:converter> and <f:validator> tag handlers, aren't they?

So why don't they cause the chicken/egg issue?

Bauke Scholtz said...

@Rafael: only if you reference a view scoped bean property in any of their attributes like so <f:validateLength minimum="#{viewScopedBean.minimum}" >

Rafael Ponte said...

Thanks, BalusC.

My question has to do with your sentence "<f:convertXxx> like <f:convertNumber>: use converter attribute or <f:converter> instead".

If <f:converter> is a tag handler, why doesn't it cause the chicken/egg issue?

Bauke Scholtz said...

@Rafael: Oh this way. Well, this is solveable with a custom converter implementation wherein the view scoped variables are obtained inside getAsObject/getAsString methods on a per-request basis instead of as tag attribtues. Alternatively, if you're using OmniFaces, you can use <o:converter>.

Rafael Ponte said...

Oh Thanks, BalusC! You're great!

Now I understood! So retrieving data from view scope is a custom converter's responsibility and not of tag handler's.

Thanks for your help and huge knowledge!

Alberto said...

I don't understand when a request scoped bean is created, I mean, is it created for each HTTP request or for a subset of the HTTP requests made?

The same with @ViewScoped, don't know if it is created for each view you arrive to or for a subset of views.

I have this doubt because apparently if you use a request scoped bean instead of a session scoped bean, you are reducing the memory used in the server, but I don't get how you reduce the memory used if the bean is created for every HTTP request.

Can you answer me please?

id khan said...

@BalusC: i have also issue related to scope please help me, i have posted question at stackOverFlow. The link is this:
<>
http://stackoverflow.com/questions/21364557/parameters-are-not-removing-scope-issue-in-screens-using-primefaces

please help me.

W L Nalaka A Wijerathna said...

Dear BalusC,

I have a ajax request inside of a h:datatable. with in the render attribute of the ajax tag I have used an output box id, at the outside to the data table. It causes the bellow error.

SEVERE: javax.faces.FacesException: contains an unknown id 'testSubTotal' - cannot locate it in the context of the component sdtChargePrice"

for this problem I got a solution, in that I put jobReservationForm:testSubTotal this is form id and the output box id.
It is worked.

My question is what is the advantage of using namingcontainers to solved this problem. Actually I don't have a clear idea regarding namingcontainers in JSF2

Prema Monica SI said...

We Recently started using JSF2.0 , moved from GWT/ GXT. It is amazing , last couple of weeks, for every issue or answers I have been looking for, I finally end up in your blog or your answers.

Thank you for the awesome work. Lot of help to others.

Biswajit Singh said...

I have recently migrated my project from JSF1.2 to JSF2.2.3

I am facing issues with where it fails with "No save state could be found".

the configuration I have is -
SAVE_STATE_METHOD = server and

javax.faces.FACELETS_RESOURCE_RESOLVER
false



javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
true


Because i am not using Facelets so i made the above change. I am still working JSP 2.0. Is there any configuration change I have to consider while moving from JSF 1.2 to JSF 2.2.3 and can avoid or fix "No save state could be found" error when we click on h:commandLInk or h:commandButton.
Any help is appreciated. I loss hope now and thought of telling my client to revert back to JSF 1.2. Not sure what to do at this moment.

Ramachandra Rao S said...

Great Post!

I have a problem on the similar lines which is related to
Richfaces - 4.3.2

current code in XHTML:

---form...start
check box component with a4j ajax event.

---- rich:collapsiblePanel...start
included with another XHTML form having rich:extendedDataTable component.
----rich:collapsiblePanel...end
.
.
mutiple collapsiblePanels.
.
---- rich:collapsiblePanel...start
another XHTML:
---form...start
LightBox Component having another form
---form...end
----rich:collapsiblePanel...end
.

.
---form...end

when ajax event happen,
the backing beans are getting updated but when I click on light box, it is retaining and displaying the last viewed report irrespective of what ever record I wish to see.

I have tried a lot of ways, the only solution i got is externally specifying all the form ids in the a4j event render list.

as I am looking out for generic way of doing this I have noticed your blog with recommendation:
Automatically fix missing JSF view state after ajax rendering

though I had implemented as you said, still the old problem persists....

any help on this is highly appriciated!