using jsf 2.x in liferay portal - download.irian.at file• we are missing high level concepts like...

Using JSF 2.x in Liferay Portal Andy Bosch, www.jsf-academy.com

Agenda

• Portals and Portlets • Motivation for JSF + Portlets • JSR-301 and others: Portlet Bridge for JSF • What is JSR-301? What is JSR-329?

• How does the Portlet Bridge work? • JSF 2.x in Liferay Portal

Who am I?

• Name: Andy Bosch

• Trainer, coach, developer, …

• Specialized in JSF and Portlets

• Expert Group member of JSR-301, JSR-329, and JSR-344

• Working with JSF since 2004

Agenda



Talking about “real Portals”

Talking about “real Portals”

Integration / Aggregation

Personalisation

Consistent look & feel

SSO

From Portals to Portlets

• A portal is responsible for the aggregation of content, applications, and services.

• Each fragment of a portal page is called a Portlet. • That way, many portlets together form a portal page and many portal pages form a portal.

à  In contrast to Portals, Portlets are standardized. The underlying standard is JSR-168.

à The latest Portlet standard, JSR-286, was published in 2008.

How does a Portlet work?

• A Portlet is triggered by the Portal (to be exact: by the Portlet container) to display itself (render phase).

• The Portlet container aggregates all fragments of the Portlets included in a page. The aggregated output is sent to the browser (e.g. as html page).

• If an action is triggered by the user (e.g. clicking on a button), the action phase of this Portlet is called. After calling the action phase, all Portlets will be rendered again.

Life cycle of a Portlet (JSR-168)

Init

Render Action

Destroy

JSR-286 (Portlet V2) extends this life cycle.

A very simple Portlet …

public class SimplePortlet extends GenericPortlet { protected void doView( ... ) { PrintWriter writer = response.getWriter(); writer.println( "Hello Portlet World" ); String link = .... writer.println( "<a href='" + link + "'> Click me</a>" ); }

public void processAction( ... ) { // TODO do some action logic } }

Functionality within JSR-168

• Definition of the Portlet life cycle • Interfaces and base classes (GenericPortlet and javax.portlet.Portlet)

• Window states and Portlet modes • Request and render parameter • Portlet sessions • Portlet preferences • Inclusion of JSP fragments • Portlet tag library

à Focus is on the Portlet itself

Current specification: JSR-286

• Almost everything from JSR-168 is still valid • Public render parameters • Portlet events • Resource serving • Portlet filters • Basis for AJAX integration

à Focus is on the interaction of Portlets

Agenda



Building applications with plain Portlet functions?

• Programming with the Portlet spec is not very convenient.

• We are missing high level concepts like page flow, bean management, conversion, validation, and many more.

• We would like to have modern UI components

We have to combine the Portlet technology with a powerful user interface framework.

The solution: JSF?

• JavaServer Faces is a framework specialized in the user interface

• JavaServer Faces is used in many projects in large and small companies.

• JavaServer Faces features useful concepts like bean management, page flow, data conversion, and data validation

• JSF is also a standard.

User interface components 16

JSF + Portlets: Isn‘t it easy?

• The problem is the “glue code”.

• We have to integrate both technologies. Each technology should keep its own functionality, but use the benefits of the other.

• We should try to minimize the integration efforts.

• Is this possible?

à Yes, as we can use JSR-301 and JSR-329.

Agenda

• Portals and portlets • Motivation for JSF + Portlets • JSR-301 and others: Portlet Bridge for JSF • What is JSR-301? What is JSR-329?


JSR-301: Portlet Bridge Specification for JavaServer Faces

• Started in December 2006 • Spec leader: Michael Freedman (Oracle) • Goal is to provide a standardised bridge for executing JSF applications within a portlet context.

• Another very important goal is to make the integration as simple as possible for the application developer.

• To be more precise, there are two specs: • JSR-301 = Portlet 1.0 (JSR-168) + JSF 1.2 • JSR-329 = Portlet 2.0 (JSR-286) + JSF 1.2 •  XXX = Portlet 2.0 (JSR-286) + JSF 2.x ?????????????

High level overview

Main challenge / goal

•  Mapping of both life cycles

JSF life cycle Portlet life cycle

Mapping of life cycles: JSF

Just to remind you: Portlet life cycle

Init

Render Action

Destroy

Mapping of life cycles: Bridge

Bridge request scope

• In JSF, the entire life cycle is executed within one request.

• In Portlets, there are two requests, one for the render phase, one for the action phase. The requests are independent of each other.

• That way, the bridge is responsible for supplying all the necessary information for JSF, even if the life cycle is sub-divided into two phases.

• That means in detail: attributes from the action phase must be stored temporarily by the bridge and set before executing a JSF render phase.

Scopes for confusion (1)

• There is an JSF request scope

• But there is also a Portlet request (action request or render request)

• Storing a Managed Bean in the JSF request scope: What does in mean for the Portlet environment?

Scopes for confusion (2)

• There is an JSF session scope

• But there is also a Portlet session. This session is devided into two parts: APPLICATION_SCOPE and PORTLET_SCOPE

• Storing a Managed Bean in the JSF session scope: Assigned to the Portlet PORTLET_SCOPE

• When aiming for IPC: Downcast and do it “manually”

Using the Portlet Bridge

1.  Develop a “normal” JSF application

2.  Remove “forbidden” tags like <html>, <body>, <head> etc.

3.  Include the JSR-301 / JSR-329 libs

4.  Provide a portlet.xml and adjust it

5.  Deploy and have fun J

Agenda

• Portals and portlets • Motivation for JSF + Portlets • JSR-301 and others: Portlet Bridge for JSF • What is JSR-301? What is JSR-329?


JSF 2.x and Portlet 2.0

• No standard available

• “Implementation first” approach to find the best possible solution

• For Liferay Portal (and perhaps others as well): www.portletfaces.org

• Base is the solution of the JSR-301/JSR-329 + extensions

What is portletfaces.org?

• Community founded by some Liferay partners

• Offers a Portlet bridge for JSF 2.x

• April 2012: Liferay took the leadership of this community

• New brand for it: Liferay Faces (umbrella project)

Liferay Faces

• Umbrella project

• Goal is to support JSF in Liferay Portal

• Liferay Faces Alloy

• Liferay Faces Bridge

• Liferay Faces Portal

Liferay Faces Bridge

• Supports the JSR-329

• JSF 2.0 and JSF 2.1 are supported (Mojarra and MyFaces)

• Should support ICEfaces, PrimeFaces and RichFaces

• Agenda for 2012: Alignment with JSR-344 (JSF 2.2)

From theory to reality

• Write your JSF application

• Provide a portlet.xml

• Add the Liferay Faces Bridge jars

• Add some magic and it should work.

Portlet definition

<portlet>

<portlet-name>MyPortlet</portlet-name> <portlet-class> javax.portlet.faces.GenericFacesPortlet </portlet-class>

<init-param> <name> javax.portlet.faces.defaultViewId.view </name> <value> /myGreatPage.xhtml </value>

</init-param>

...

Advanced units: Portlet events and JSR-329

• JSR-286 Portlets can send Events

• JSR-286 Portlets can receive Events

• JSF can send Events in the sense of Portlets (that is communicating with other Portlets)

•  So we have to “bridge” again between the two worlds

Portlet Events: How to solve it?

• Register an event handler in portlet.xml

• The handler will be triggered upon incoming events.

• The handler provides you with access to the FacesContext.

Portlet events - example

<init-param>

<name>

javax.portlet.faces.bridgeEventHandler

</name>

<value>

de.jsfportlets.handler.MyEventHandler

</value>

</init-param>

Portlet events - example

public EventNavigationResult handleEvent( FacesContext jsfContext, Event evt ) {

MyJSFBean myBean = Facade.getBean()

myBean.setNewValue( evt.getValue() );

return null;

}

Back again to our confusion page

• Do you remember the different scopes?

• JSF request scope should last for one “JSF request”

•  Within Portlets, it could live “forever”

•  Within the Liferay Bridge, they decided to let the BridgeRequestScope end with the end of the RenderRequest.

•  ...

More on the way

• Public Render Parameters are supported as well

• Portlet Preferences can be evaluated automatically

• Liferay Faces already has an upload component

• Extended EL possibilities (access to portlet specific objects)

•  ...

Conclusion

• General statement: A combination of JSF and Portlets is possible.

• You have to use specific bridges for JSF 2.x. There is no general standard.

• The bridge, specifically for Liferay, works quite good and looks very mature. But including JSF Component Libraries could be a pain.

• Hoping for a JSR to come …

Do you have questions?

Or write an e-‐mail to: andy.bosch@jsf-‐academy.com

Follow me on Twi1er: @andybosch

using jsf 2.x in liferay portal - download.irian.at file• we are missing high level concepts like...

Documents