Flash Scope

Flash Scope provides a way to pass objects between various JSF pages or the user views generated by the faces lifecycle. The objects put in Flash scope are available only in the next view and then are cleared out.


In JSF pages you can put or get value from Flash scope in the following ways

1) Put a value in using <c:set>

<c:set target="#{flash}" property="i2" value="Incept"></c:set>

view raw flash2 hosted with ❤ by GitHub

2) Put a user entered value in flash scope.
This comes in handy when we don't want to map a form field to a backing bean but still want it to make it available in the backing bean or to the next view.

	<h:outputText style="color: blue; font-weight: bold" value="flash.i1= "/>
	<h:inputText id="i1" label="Input1: " value="#{flash.i1}"></h:inputText>

view raw flash1 hosted with ❤ by GitHub

3) Read/Print value from Flash Scope in JSF 

	<h:outputText value="#{flash['i1']}"></h:outputText>
	<h:outputText value="#{flash.keep.i2}"></h:outputText>

view raw flash3 hosted with ❤ by GitHub

".keep" makes the variable available in the next view as well.

3) Read/Print value from Flash Scope in Backing Bean

	public String someViewAction() {
	System.out.println("flashExampleBean.someViewAction called");
	Flash fl = FacesContext.getCurrentInstance().getExternalContext().getFlash();
	Set flSet = fl.keySet();
	System.out.println("FL set size = " + flSet.size()
	+ ", i1 value=" + fl.get("i1")
	+ ", i2 value=" + fl.get("i2")
	+ ", i3 value=" + fl.get("i3"));
	return "index_1";
	}

view raw flash4 hosted with ❤ by GitHub

To keep" flash variables available to next view - fl.setKeepMessages(true);
To put a new object in flash scope - fl.put("Greetings", "Hello")

Download Code

How to call a method during various JSF lifecycle phases

In order to invoke a method during various lifecycle phases on JSF, you can either use JSF 2.0 <f:viewAction>tag. or <f:event> tag.
The functioning of both tags is very similar, both need a definition for trigger mechanism(when to invoke method) and action mechanism(which method to invoke). These tags are defined in in the meta definition section of the page as follows

<f:viewAction>

This action component specifies an application-specific command (or action), using an EL method expression, to be invoked during one of the JSF lifecycle phases,

<f:metadata>
  <f:viewAction phase="PROCESS_VALIDATIONS" action="#{person.init()}"/>
</f:metadata>

The attributes "action" and "phase" define which method to invoke for an event.
 action: EL method expression i.e. method to invoke. e.g.#{person.init()}
 phase: Name of the event for which to install a listener.


The above tag will result in person.init() method invoked before the "Process Validation" JSF lifecycle phase.

The init method (in the "Person" BackingBean) can be as follows:

public String init() {      
  // do something like get List of persons from database
}

The "phase" attribute can have one of the possible values.

1. APPLY_REQUEST_VALUES
2. PROCESS_VALIDATIONS 
3. UPDATE_MODEL_VALUES 
4. INVOKE_APPLICATION 

The default is INVOKE_APPLICATION.

<f:event> 

This specifies an application-specific action, using an EL method expression, to be invoked during one of the JSF lifecycle phases.

<f:metadata>

  <f:event type="preRenderView" listener="#{person.init()}"/>

</f:metadata>

The attributes "listener" and "type" of <f:event> define which method to invoke for an event.
 listener: EL method expression i.e. method to invoke. e.g.#{person.init()}
 type: Name of the event for which to install a listener.

As a result of the above <f:event> declaration, JSF run-time invokes person.init() prior to rendering the components.

The init method (in the "Person" BackingBean) is shown as follows:

public void init() {        

  // do something like get List of persons from database

}


The "type" attribute can have one of the possible values.

1. preRenderComponent
2. preRenderView
3. postAddToView
4. preValidate  
5. postValidate

<f:viewAction> differs from <f:event> in the following manner

• View actions, by default is not invoked in post-backs; where as in f: event, post-backs needs to be programmatically checked.
• View actions have navigation capabilities, View actions support both implicit and explicit navigation.  (action method returns backs a view or in xml), where as in f:event one needs to manage navigation programmatically using response.sendRedirect or using NavigationHandler
• View actions can be triggered early on, before a full component tree is built, resulting in a lighter weight call.

Call a method in Backing Bean prior to page rendering

A view is rendered by JSF engine in "Render Response Phase". In order to invoke a method right before a View is rendered in the "Render Response Phase", you can use jsf 2.0 <f:event>. This tag is defined in in the meta definition section of a page as follows

<f:metadata>

  <f:event type="preRenderView" listener="#{person.init()}"/>

</f:metadata>

The attributes "listener" and "type" of <f:event> define which method to invoke for an event.
 listener: EL method expression i.e. method to invoke. e.g.#{person.init()}
 type: Name of the event for which to install a listener.

As a result of the above <f:event> declaration, JSF run-time invokes person.init() prior to rendering the components.

The init method (in the "Person" BackingBean) is shown as follows:

public void init() {        

  // do something like get List of persons from database

}

The JSF run-time invokes the method defined by listener, as per the event "type". "type" attribute can take one of the following values

1. postAddToView:  runs right after the component is added to view during view build time (which is usually during restore view phase, but can also be during render response phase, e.g. navigation).
2. preValidate:  runs right before the component is to be validated (which is usually during validations phase, but can also be apply request values phase if immediate="true").
3. postValidate: runs right after the component is been validated (which is usually during validations phase, but can also be apply request values phase if immediate="true").
4. preRenderView: runs right before the view is rendered during render response phase.
5. preRenderComponent: runs right before the component is rendered during render response phase.

Note: Above list is from Balusc response on StackOverFlow(http://stackoverflow.com/questions/13999099/jsf-execution-order-of-fevents)

Pass bean properties to JavaScript function

In the JavaScript function call include bean properties in quotes

for example:

<h:form>

  <h:commandButton type="button" value="JavaScript Call" onclick="printInfo('#{person.firstName}', '#{person.lastName}')"/>

</h:form>

The JavaScript function for this is shown in the following code:

<script type="text/javascript">

  function printInfo(name, lastName) {

    alert("Name: " + name + " " + lastName);

  }

</script>

Contexts and Dependency Injection(CDI) - Producer

@Produces is a CDI mechanism which allows defining a source for injection. One can use Producer Method or Producer field to generate objects.


Here is brief explanation from JEE 6 tutorial:

A producer method generates an object that can then be injected. Typically, you use producer methods in the following situations:

• When you want to inject an object that is not itself a bean
  
• When the concrete type of the object to be injected may vary at runtime
  
• When the object requires some custom initialization that the bean constructor does not perform

(Code snippet from attached Source)

	@Produces
	@Greeting
	public String getMessage() {

view raw CDI - Producer hosted with ❤ by GitHub

A producer field is a simpler alternative to a producer method; it is a field of a bean that generates an object. It can be used instead of a simple getter method. Producer fields are particularly useful for declaring Java EE resources such as data sources, JMS resources, and web service references.

(Code snippet from attached Source)

	@TrType
	@Produces
	@Transporter tr;

view raw gistfile1.txt hosted with ❤ by GitHub

This is how an Object in Injected

(Code snippet from attached Source)

This example shows both ways of declaring a producer and Injection.

Click here to download source code


Prasanna Bhale

JSF2.2 ViewScope Using CDI

JSF 2.0 introduced annotation @ViewScoped; A bean annotated with this scope maintained its state as long as the user stays on the same view(reloads or navigation - no intervening views).

One problem with the @ViewScoped is that it doesn't work with CDI (@Named); so one had to annotate bean as @ManagedBean to be ViewScoped.

JSF2.2 has introduced a NEW annotation @ViewScoped in javax.faces.view.ViewScoped (NOT reusing the existing javax.faces.bean.ViewScoped) which is CDI compatible.

Here is a working sample using Glassfish B4 v72.

Click here to download source code




Prasanna Bhale

JSF 2.2 Faces Flow

JSF 2.2 Faces Flow           

As the API for JSF 2.2 is evolving, I struggled a bit to get Arun Gupta's Faces Flow sample code (from blog JSF 2.2 Faces Flow )working.

I have finally got it to work after some minor API/code changes and so, here with sharing with rest of developer's community.

Download the source code from here

Click here to download source code


Prasanna Bhale