An icefaces-jsf sample is provided within Liferay's plugins set. It works great.
sample-icefaces-jsf-1.1-sun-facelets-portlet-5.1.0.1.warI'm integrating services provided in ext and I'm wondering about the state management for the backing bean. The sample's author makes the following comments:
--snip--
* This class is the backing bean behind the JobApplication.jspx file. It
* contains bean properties to store the values of each ICEfaces component
* on the page. In addition, it contains a submit action callback, so that
* the job application form can ....
--snip--
public class JobApplication {
public JobApplication() {
// Store the portlet preferences as a bean property because of ICE-1625.
// When using normal JSF, this constructor will get called each time a
// request is made. This is a little inefficient, but it's a coding
// tradeoff to make things work with both normal JSF and ICEfaces 1.6.0.
_portletPreferences = JSFPortletUtil.getPortletPreferences(
FacesContext.getCurrentInstance());
}
The bean provides a bunch of getters/setters that reference member variables. There's also a submit handler which can be used to process the user's input data and store it using services provided by ext. My concern, however, is the initialization of the bean with respect to the current user. The author's comments indicate the bean will be created for each request when using "normal JSF". This suggests the bean will not get recycled nor will it be used in another session. If this is true, I can use the constructor to initialize the member variables with the current user's private data and not worry about the bean instance finding its way to another user.
But if I were doubtful, I could maintain the user's id as a member to the bean instance and verify the user within each getter prior to returning data, but this can be expensive and I'm wondering if it's necessary. Is there a specification that describes the bean's lifecycle with respect the current user's session?
