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>
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.
3) Read/Print value from Flash Scope in JSF
".keep" makes the variable available in the next view as well.
3) Read/Print value from Flash Scope in Backing Bean 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
Thursday, August 7, 2014
Wednesday, August 6, 2014
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: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.
The default is INVOKE_APPLICATION.
<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.
The "type" attribute can have one of the possible values.
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.
- APPLY_REQUEST_VALUES
- PROCESS_VALIDATIONS
- UPDATE_MODEL_VALUES
- 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:
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.
- preRenderComponent
- preRenderView
- postAddToView
- preValidate
- 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:
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
The JSF run-time invokes the method defined by listener, as per the event "type". "type" attribute can take one of the following values
- 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).
- 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").
- 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").
- preRenderView: runs right before the view is rendered during render response phase.
- 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)
Tuesday, August 5, 2014
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>
Subscribe to:
Posts (Atom)