UI Development in JEE - JSF and ICEFaces

Preview:

Citation preview

UI Development in JEE:

JSF and ICEFaces

Mario Rodriguez V

Agenda

• Motivation

• History

• Introduction to JSF

• JSF architecture• JSF architecture

• Introduction to ICEfaces

• ICEFaces architecture

Motivation

• Web programming is more difficult than GUI

programming

– Users need to handle many subtle details related to HTML and HTTP

– Browser idiosyncrasies

– Web is more restricted than GUI

• Web frameworks such as Struts, Tapestry, Spring MVC,

Web Work made life easier and mess everything up at Web Work made life easier and mess everything up at

the same time

– MVC and separation of concerns makes Web easier

– MVC WAR

• JSF to the rescue

JSF History

• JSR-127 defined and released the JSF 1.1 standard in

2004

– The JSR was co-chaired by Craig McClannahan, inventor Struts

• JSR-252 defined and released JSF 1.2 in 2006

– Introduced a dependency on Java 5.0 and Servlet 2.5/JSP 2.1

• JSR-314 began its work in May 2007 and plans to • JSR-314 began its work in May 2007 and plans to

define and release JSF 2.0 by 2009

– AJAX support

Introduction to JSF

– Java Server Faces (JSF) is the standard web application

framework for Java EE

– Enable RAD development

• Eliminate cumbersome code required in web dev

• Make life easier for non-J2EE developers

– Event-driven component model

– Use UI reusable components, not actions. More like Swing, – Use UI reusable components, not actions. More like Swing,

less like Struts

– Extensible standard to allow growth and customization

– Internationalization: Views can manifest themselves in

different languages

Introduction to JSFIntroduction to JSF

JSF consists of

– Java classes

• “Faces” components: server-side equivalents of HTML

components (text,buttons,check boxes, etc.)

• FacesServlet (web.xml)

• Helper classes (converters, validations, etc)

– Tag libraries

• Sun Microsystems tag libraries• Sun Microsystems tag libraries

• Used in JSPs and Facelets

– Configuration file (faces-config.xml)

• JSF project configuration: navigation between pages,

JavaBeans used by JSF

JSF Implementations

• The JSF API is basically a set of Java interfaces and abstract

classes that define a contract by which a Reference

Implementation (RI) must fulfill.

• There are two JSF RIs available, both in open-source:

– Sun RI, code-named “Mojarra”– Sun RI, code-named “Mojarra”

• jsf-api.jar

• jsf-impl.jar

– Apache MyFaces RI

• myfaces-api.jar

• myfaces-impl.jar

JSF HTML Component Tags

• The JSF API requires the RI to supply a handful of basic

UI components that manifest themselves as HTML:

<h:form />

<h:inputText />

<h:inputTextarea />

<h:inputSecret />

<h:inputHidden />

<h:commandButton />

<h:commandLink />

<h:message />

<h:messages />

<h:panelGrid />

<h:selectOneListbox />

<h:selectOneMenu />

<h:selectOneRadio />

<h:selectBooleanCheckbox />

<h:selectManyCheckbox /><h:inputHidden />

<h:outputLabel />

<h:outputLink />

<h:outputFormat />

<h:outputText />

<h:panelGrid />

<h:panelGroup />

<h:dataTable />

<h:column />

<h:selectManyCheckbox />

<h:selectManyListbox />

<h:selectManyMenu />

JSF Core Component Tags

• The JSF API requires the RI to supply a handful of core

UI components:

<f:view />

<f:subview />

<f:facet />

<f:attribute />

<f:param />

<f:converter />

<f:convertDateTime />

<f:convertNumber />

<f:validator />

<f:validateDoubleRange />

<f:loadBundle />

<f:selectItems />

<f:selectItem />

<f:verbatim />

<f:param />

<f:actionListener />

<f:valueChangeListener />

<f:validateDoubleRange />

<f:validateLength />

<f:validateLongRange />

• Most of the core tags represent objects that you would add

to HTML components to augment their functionality

• Complete list of tags with example screenshots can be

found at www.corejsf.com

JSF Component Suites

• The JSR-127 Group wanted a competitive marketplace

of JSF components. For this reason JSF API contains

only a minimal set

• The first “component suites” arrived shortly after JSF

1.1 was released in March, 2004:1.1 was released in March, 2004:

– Sun Woodstock, Apache MyFaces Tomahawk

• Other Suites: ICEFaces,RichFaces, Spring JSF, ADF

Component Tags

• Component tags are placed on JSF pages/views:<h:outputText />

• Tag attributes allow developers to customize the appearance and

behavior of components:<h:outputText value=“Hello World” rendered=“true” />

• Tags are nested in a parent-child containment format

<h:form><h:form>

<h:panelGroup>

<h:outputLabel for=“fullName” />

<h:inputText id=“fullName” />

</h:panelGroup>

</h:form>

• The JSF framework manages the hierarchy in a component tree on

the server

Component Tree (CT)

• Although components are specified declaratively using

XML markup, their runtime representation are Java

objects maintained in a CT

• When the view (JSP or facelet page) is parsed by the

view-handler, all JSF component tags are translated to

Java class instances that live the CT on the server

JSF ArchitectureJSF Architecture

JSF Architecture

• JSF is a web application framework that implements

the MVC design pattern, and a clean separation of

concerns:

– Model: Contains UI data and handles database interactions

– View: Defines the user interface with a hierarchy of

components using a declarative markup language

– Controller: Handles user interactions and navigation between

views

JSF MVC: Model

• The model layer of the MVC design pattern is responsible for

managing data

• JSF implements the model layer with its managed bean

facility

JSF MVC• Managed beans are

specified in the

View

Model

Controller

JSF MVCspecified in the

faces-config.xml

file, implemented as

Plain Old Java

Objects (POJOs) with

an empty constructor

Managed Bean Scopes

• The JSF managed bean facility provides three scopes in which managed-

beans may exist:

– request:

• Very short lifespan –created when the request begins, and

scheduled for garbage collection when the request completes

• For efficiency, try to place managed beans in request scope

– session:

• The HttpSession can be used to store application state, such as • The HttpSession can be used to store application state, such as

the contents of a shopping cart

• The lifespan of an HttpSession is determined by a timeout or by

invalidation (when a user logs out)

– application:

• Lifespan continues as long as the web application is deployed

• Useful for sharing data between users

Managed Bean Scopes (Cont.)

• There is general consensus in the JSF community that

there needs to be another scope which would be longer

than a request, but shorter than a session

• JSF 2.0 will introduce several new scopes, but until

then, the following projects have attempted to solve

this problem:this problem:

– Spring Web Flow: Flows

– JBoss Seam: Conversation Scope

– Apache Shale: Dialog Manager

– Apache MyFaces Orchestra: Conversation Scope

JSF MVC: View

• The view layer of the MVC design pattern requires a Page

Description Language (PDL) to describe the contents of the

view

JSF MVC• The JSF Expression

Language (EL) is

View

Model

Controller

JSF MVCLanguage (EL) is

used to bind the

view to the modelEL Bindings

JSF MVC: View (Cont.)

• Default JSF view-handler is JSP (JSF 1.1 and 1.2)

• Facelets is an alternative view handler

– Facelets will be the default view-handler in JSF 2.0

– Facelets can be up to 30% faster at compiling pages than JSP

– Templating features

Expression Language (EL)

• EL is used to bind the view to the model

– ValueBinding

– MethodBinding

• Distinction between JSF 1.1 and JSF 1.2 EL

– #{} Runtime (deferred) evaluation

– ${} Compile-time (immediate) evaluation

• What happens when an expression is evaluated?

– Bean look-up

– Reflective bean property resolution

Implicit EL Objects and Class Types

• cookie: Map

• facesContext: FacesContext

• header: Map

• headerValues: Map

• param: Map

• paramValues: Map• paramValues: Map

• requestScope: Map

• sessionScope: Map

• applicationScope: Map

• initParam: Map

• view: UIViewRoot

EL Operators

• Arithmetic: +, -, *, / (or div), % (or mod)

• Relational: == (or eq), != (or ne), < (or lt), > (or

gt), <= (or le), >= (ge)

• Logical: && (or and), || (or or), ! (or not)

• Conditional: A ? B : C

• Empty: empty (true if variable is null, an zero-length • Empty: empty (true if variable is null, an zero-length

string, array, Map, or Collection)

<h:panelGroup

rendered=”#{mybean.value ne empty and mybean.rendered}” >...

</h:panelGroup>

JSF MVC: Controller

• The controller requires a mechanism for navigating from one

view to another

• JSF implements the controller layer with navigation-

handler in combination with page backing beans

JSF MVC• The default JSF

navigation-handler

ViewView

Model

Controller

JSF MVCnavigation-handler

supplies

action+outcome

style navigation rules ActionOutcome

Next View

JSF Lifecycle Diagram

APPLY_REQUEST_VALUES

ProcessEvents

ProcessDecodes

RESTORE_VIEW

BuildComp Tree

ParsePDL

ApplySaved State(Post Only)

HTTP POST / Partial Submit

PROCESS_VALIDATIONS

ProcessEvents

ProcessValidators

FacesRequest

HTTPGET

If immediate=“true” then Actions, Action Listeners, and Value Change Listeners fire here

<f:view>

<h:form>

<h:outputLabel />

<h:inputText />

Facelet View Markup UIViewRoot

HtmlForm

HtmlOutputLabel

Component Tree

Value Change Listeners Fire

Here

Conversion/Validation Failure

UPDATE_MODEL_VALUES

ProcessUpdates

ProcessEvents

INVOKE_APPLICATION

ProcessApplication

ProcessEvents

RENDER_RESPONSE

ProcessRenderers

SaveComp State

Conversion/Validation Success

FacesResponse

Actions & Action Listeners fire

here

<h:inputText />

<h:commandButton />

</h:form>

</f:view> HtmlCommandButton

HtmlInputText

Introduction to ICEFacesIntroduction to ICEFaces

Introduction to ICEfaces

• What is ICEfaces?

– A JSF extension (not a reference impl)

– An AJAX-based Component Suite

– AJAX Push implementation

– A server-side Framework (minimal Javascript)

• Why not Javascript?

– Cross-browser compatibility issues

– Hard to find highly skilled JS developers

– Security Issues

– Challenging to maintain a large Javascript codebase

Compatibility of ICEfaces

– Java App Servers

– Web Browsers

– Integration with other Java frameworksSEAM

– Strong integration with other Java Tooling

Portal

Major Benefits

• Automatic AJAX requests/updates

• Partial submit / Direct-to-DOM rendering

• AJAX Push

– Server-initiated rendering updates to the client

• No more constraint of the traditional web development

– Integral to ICEfaces– Integral to ICEfaces

• Components are Ajax Push Ready

– Collaborative Web Applications

• Enables next generation web 2.0

– (Forums, Chat, Auctions …)

– Real-time updates

ICEfaces Demos

• Component Showcase

• Auction Monitor

ICEFaces ArchitectureICEFaces Architecture

ICEfaces Architecture

• Standard J2EE architecture diagram

ICEfaces Architecture

• The ICEfaces framework

Understanding ICEfaces

• Apps are server centric

– When the page is first requested, all of the presentation is

sent to the client, including a JavaScript bridge (is the

communication mechanism between server and client)

– When the user interacts with the client, events are sent back

to the server that may alter application state and change the

page on the server

– When the page changes on the server, only those incremental

changes are delivered back to the client

– This feature is called the Direct-to-DOM (D2D) approach

Direct-to-DOM (D2D) Rendering

• Ability to render a JSF component tree directly into a W3C standard DOM data structure

• ICEfaces provides a Direct-to-DOM RenderKit for the standard

HTML basic components available in JSF

• The basic Sun JSF components render themselves by generating

plain HTML text

• ICEfaces JSF components do not render through HTML text, but • ICEfaces JSF components do not render through HTML text, but

through DOM updates

Direct-to-DOM (D2D) Rendering

• D2D rendering:

– D2D rendering happens mostly under the cover

– Its purpose is to enable the AJAX bridge to do DOM diff’ing

between the server and the client.

DOM(Server)

DOM(Client)

Incremental DOM Updates

Ajax Bridge

Partial Submit

• Introduces a fine-grained user interaction model for form processing

• Submit is partial in the sense that only partial validation of the form will

occur.

• The standard JSF validator mechanism can be leveraged, or any other

arbitrarily complex or simple evaluation logic can be applied.

The AJAX Bridge

• Lightweight AJAX bridge to deliver presentation changes to the client browser and to communicate user interaction events back to the server-resident JSF application.

• Application-level Ajax

• ICEfaces restricts Ajax to– Incremental presentation updates

– User event capture and transmission

• Enables thin client scalability

• Handle browser idiosyncrasies• Handle browser idiosyncrasies

• Eliminate the need for JavaScript development

Recommended