HeadPhaseListener (Liferay Faces Bridge 3.2.4-ga5 API)

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

com.liferay.faces.bridge.renderkit.html_basic
Class HeadPhaseListener

java.lang.Object
  com.liferay.faces.bridge.renderkit.html_basic.HeadPhaseListener

All Implemented Interfaces:: Serializable, EventListener, javax.faces.event.PhaseListener

public class HeadPhaseListener
extends Object
implements javax.faces.event.PhaseListener
extends Object
implements javax.faces.event.PhaseListener

This class is a JSF PhaseListener that listens to the PhaseId.INVOKE_APPLICATION and PhaseId.RENDER_RESPONSE phases of the JSF lifecycle. Along with HeadManagedBean and HeadRendererBridgeImpl, this class helps provides a solution to an issue regarding Ajax-initiated execution of navigation-rules in a portlet. When a portal page is first rendered by the portal, all of the portlets on the page participate in the PortletRequest.RENDER_PHASE of the Portlet lifecycle. During this initial HTTP-GET operation, the bridge has the ability to add JavaScript and CSS resources to the <head> section of the rendered portal page. Subsequent Ajax-initiated execution of the JSF lifecycle via the PortletRequest.RESOURCE_PHASE are NOT ABLE add resources to the to the <head> section.

Author:: Neil Griffin
See Also:: http://issues.liferay.com/browse/FACES-180, Serialized Form

Constructor Summary
`HeadPhaseListener()`

Method Summary
`void`	`afterPhase(javax.faces.event.PhaseEvent phaseEvent)`
`protected void`	`beforeAjaxifiedRenderResponsePhase(javax.faces.event.PhaseEvent phaseEvent)` This method is called before the `PhaseId.RENDER_RESPONSE` phase of the JSF lifecycle is executed.
`protected void`	`beforeApplyRequestValuesPhase(javax.faces.event.PhaseEvent phaseEvent)` This method is called before the `PhaseId.APPLY_REQUEST_VALUES` phase of the JSF lifecycle is executed.
`void`	`beforePhase(javax.faces.event.PhaseEvent phaseEvent)`
`javax.faces.event.PhaseId`	`getPhaseId()`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

HeadPhaseListener

public HeadPhaseListener()

Method Detail

afterPhase

public void afterPhase(javax.faces.event.PhaseEvent phaseEvent)

Specified by:: afterPhase in interface javax.faces.event.PhaseListener

beforePhase

public void beforePhase(javax.faces.event.PhaseEvent phaseEvent)

Specified by:: beforePhase in interface javax.faces.event.PhaseListener

beforeAjaxifiedRenderResponsePhase

protected void beforeAjaxifiedRenderResponsePhase(javax.faces.event.PhaseEvent phaseEvent)

This method is called before the PhaseId.RENDER_RESPONSE phase of the JSF lifecycle is executed. The purpose of this timing is to pick up where the #beforeInvokeApplicationPhase(PhaseEvent) method left off. It might be the case that a navigation-rule has fired and a NEW JSF view has been loaded up after the PhaseId.APPLY_REQUEST_VALUES phase (in the case of immediate="true") or the PhaseId.INVOKE_APPLICATION phase (in the case of immediate="false") has completed. If this is the case, then the list of head resourceIds in the HeadManagedBean needs to be repopulated from the list found in the Flash scope.

beforeApplyRequestValuesPhase

protected void beforeApplyRequestValuesPhase(javax.faces.event.PhaseEvent phaseEvent)

This method is called before the PhaseId.APPLY_REQUEST_VALUES phase of the JSF lifecycle is executed. The purpose of this timing is to handle the case when the user clicks on a UICommand component (like h:commandButton or h:commandLink) that has been either Auto-ajaxified by ICEfaces, or manually Ajaxified by the developer using code like the following:

<f:ajax execute="@form" render=" @form" />

When this happens, we need to somehow remember the list of JavaScript and/or CSS resources that are currently in the <head> section of the portal page. This is because a navigation-rule might fire which could cause a new view to be rendered in the PhaseId.RENDER_RESPONSE phase that is about to follow this PhaseId.APPLY_REQUEST_VALUES phase. The list of resources would be contained in the HeadManagedBean ViewScoped instance that is managed by the JSF managed-bean facility. The list would have been populated initially in the HeadManagedBean by the HeadRender during the initial HTTP-GET of the portal page. The way we "remember" the list is by placing it into the JSF 2 Flash scope. This scope is used because it is very short-lived and survives any navigation-rules that might fire, thereby causing the rendering of a new JSF view.

The story is continued in the #beforeRenderResponsePhase(PhaseEvent) method below...

getPhaseId

public javax.faces.event.PhaseId getPhaseId()

Specified by:: getPhaseId in interface javax.faces.event.PhaseListener