Upload
moises-kebede
View
71
Download
6
Embed Size (px)
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