}w!"#$%&'()+,-./012345<ya

Transcription

1 MASARYK UNIVERSITY FACULTY OF INFORMATICS }w!"#$%&'()+,-./012345<ya Comparison of AJAX JSF Libraries Functionality and Interoperability DIPLOMA THESIS Bc. Pavol Pitoňák Brno, June 2011

2 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Bc. Pavol Pitoňák Advisor: Mgr. Marek Grác ii

3 Acknowledgement I would like to thank my supervisor, Mgr. Marek Grác, my consultant, Ing. Jiří Pechanec, and RichFaces team, especially Lukáš Fryč, for their guidance and support throughout my work on this thesis. Many thanks also go to my family, girlfriend, and close friends who supported me while working on this thesis. iii

4 Abstract This thesis compares functionality of four popular JavaServer Faces component libraries RichFaces, ICEfaces, OpenFaces, and PrimeFaces. This thesis demonstrates differences between them, highlights their unique features, and research their interoperability. A demo application that would demonstrate interoperability of these libraries is created as a part of the thesis. iv

5 Keywords Java Server Faces, JSF, RichFaces, ICEfaces, PrimeFaces, interoperability, web framework, Rich Internet Applications v

6 Contents 1 Introduction The JavaServer Faces Framework History of JavaServer Faces Key Terms JSF Application The Request Processing Lifecycle The Navigation Model Managed Beans and Scopes The Facelets View Declaration Language Composite Components Resource Handling Component Libraries Ajax and Core Components Ajax in JSF 2 and in Component Libraries Region Command Button and Command Link JavaScript Function Queue Status Poll Push Input Components Calendar Inplace Inputs Autocomplete Slider Spinner File Upload Output Components Progress Bar Tree Panels Panels in RichFaces Panels in PrimeFaces Panels in OpenFaces Panels in ICEfaces Iteration Components RichFaces Repeat, List and Data Grid RichFaces Data Table vi

7 7.3 RichFaces Extended Data Table RichFaces Data Scroller OpenFaces ForEach OpenFaces Data Table PrimeFaces Data Grid PrimeFaces Data List PrimeFaces Data Table ICEfaces Data Table Charts Charts in PrimeFaces Charts in OpenFaces Charts in ICEfaces Validation Faces Validation Bean Validation Client Side Validation Cross-field Validation Messages Captcha Conclusion Bibliography A Sample Use of RichFaces Sub Table B Sample Use of Sorting in RichFaces Table C Metamer Screenshot D Contents of Attached CD vii

8 1 Introduction Rich Internet Applications (RIA) became extremely popular in last couple of years. A Rich Internet Application is a web application that has many of the characteristics of a desktop application, typically delivered either by way of a site-specific browser, via a browser plugin, independent sandboxes, or virtual machines.[1] The three most common platforms are Adobe Flash, Microsoft Silverlight and Java. Although all these platforms are mature, stable and widespread, their biggest disadvantage is that they all depend on plugins installed in user s web browser. On the other hand, new web standards such as HTML 5 are being developed in order to provide advanced features need by RIAs out-of-the-box. HTML 5 will contain new elements for handling multimedia (video and audio), a canvas element and improved integration of SVG content. Next, there are planned new semantic elements for page header, articles and sections. Several new APIs are about to be introduced for offline storage database (also known as Web Storage), drag-and-drop, geolocation, indexed database, an API for handling file uploads and file manipulation, and many more. Although latest versions of most popular browsers, namely Google Chrome, Mozilla Firefox, Apple Safari and Microsoft Internet Explorer support many HTML 5 features, it is expected to become a standard in 2014.[2] Therefore, most of modern web frameworks uses a mixture of HTML 4 and some proprietary technologies such as Adobe Flash or Microsoft Silverlight. In the Java world, there are several web frameworks and standards for creating rich internet applications. In March 1998, the Java Servlet API was introduced. Prior to servlets, Java was not widely used as a server-side technology for web applications. Unlike other proprietary web server APIs, the Java Servlet API provided an object-oriented design approach and was able to run on any platform where Java was supported. Since the Java Servlet API provided a low-level handling of HTTP requests, it was tedious and error-prone to generate HTML, e.g.: 1 out.println("<img id=\"cat\" src=\"cat.png\"/>"); Notice how the quote symbols ( ) have to be escaped. Because of above-mentioned problems of the Java Servlet API, a new technology called JavaServer Pages (JSP) was introduced. JSP was built on top of servlets and provided a simpler solution to generating large amounts of dynamic HTML. JSP were using a mix of two basic content forms, scriptlets and markup. Markup is typically HTML with some special JSP tags, while scriptlets are blocks of Java code. When a page is requested, it is translated into servlet code that is then compiled and immediately executed. Subsequent requests to the same page simply invoke generated servlet for the page. Simple page might look like this: 1 <%@ page errorpage="myerror.jsp" %> 1

9 2 page import="com.foo.bar" %> 3 <html> 4 <body> 5 <%! int serverinstancevariable = 1;%> 6 <% int localstackbasedvariable = 1; %> 7 <table> 8 <tr> 9 <td> 10 <%= tostringorblank( "expanded inline data " + 1 ) %> 11 </td> 12 </tr> 13 </table> INTRODUCTION The Java Platform, Enterprise Edition (J2EE, later renamed to JEE) contained both Servlet API and JavaServer Pages right from the first version. Although JSP was an improvement, it was not a complete solution. Developers used to use a lot of Java code in JSPs making them hard to maintain. Thus, some separation of application logic and view was needed. What was needed was an implementation of model-viewcontroller design pattern. The model-view-controller (MVC) was first described in 1979 by Trygve Reenskaug.[3] The MVC pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes: [4] model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller); view manages the display of information; and controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. Because of above mentioned issues with JSP and the need of MVC, several web frameworks were created. They could be divided into two major groups by a paradigm they use request based (e.g. Struts or Stripes) and component based (e.g. Wicket, Tapestry, Google Web Toolkit and JavaServer Faces). A request based framework basically gets user s request, then determines what the application should do and gives the response back to the user. On the other hand, in a component based framework there is no clear sense of the flow from front to back. The developer has to think not in actions but in components. JavaServer Faces (JSF) is based on components but is somehow similar to request based frameworks. Struts became one of the most dominant Java web frameworks and was donated to the Apache Foundation in May Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top level Apache project in According to Edward Burns, [5] the Java Community Process (JCP) saw the benefits that Struts offered by explicitly following the MVC approach. However, Struts lacked a robust way to handle the view tier. 2

10 1. INTRODUCTION To address this need, several leading software vendors, including Sun, Oracle, IBM, and BEA, met through the JCP in 2001 and voted to proceed with a comprehensive and detailed specification for building Java web applications. JavaServer Faces became part of the Java EE in version 5 (May 2006). Since it contained only few basic components, soon several component libraries with advanced features were created. These libraries brought Ajax 1 support and various visual components such as calendar, spinner, slider or advanced tables. Despite the fact that they all were built on top of a standard, they did not work together well, if at all. JEE 6 (December 2009) introduced JSF 2.0 which added many missing features. Since many developers wanted to use components from several JSF libraries, JSF 2.0 were designed with interoperability in mind. However, the JSF specification does not prescribe implementation details. The main goal of this thesis is to compare functionality of three JSF open source component libraries (ICEfaces, Prime- Faces, and OpenFaces) with RichFaces and find out how they inter-operate. Author of this thesis works at Red Hat in RichFaces team. This work will help RichFaces team to understand strengths and weaknesses of RichFaces components. The work is divided into several chapters. The second chapter describes the history of JavaServer Faces and new features of JSF 2. There are also above-mentioned component libraries introduced. The following chapters describe functionality and interoperability of various groups of components Ajax, input, output, panels, charts and other components. The last chapter describes validation of forms on the pages. It describes three different mechanisms for validation. 1. AJAX is an acronym for Asynchronous JavaScript and XML. In this work it will be referred to as Ajax because this name is usual in JSF community. 3

11 2 The JavaServer Faces Framework 2.1 History of JavaServer Faces JavaServer Faces is a standard component-oriented user interface (UI) framework for the Java EE platform. JSF offers an ecosystem of portable UI component libraries and extensions. JSF was created through the Java Community Process (JCP) by a group of technology leaders. The first version of JSF (1.0) was introduced in the first half of March 2004 as Java Specification Request (JSR) along with J2EE 1.4. After that, a revised version (1.1) was release in late May JSF 1.1 was only a bug-fixing release, it did not contain any specification changes nor HTML renderkit changes. The specification was led by Edward Burns (Oracle) and Craig R. McClanahan (Sun Microsystems). The objective of the specification was to establish a standard API for creating Java web application GUIs which would eliminate the burden of creating and maintaining GUI infrastructure for developers. The specification did not have any dependency on specific operating system nor CPUs. The API was created with internationalization and localization in mind. Two years later, JSF 1.2 was introduced as JSR The specification was released in May 2006 and after that, three reviewed versions were released (last in July 2008), all targeted the J2EE 5.0 Platform. The specification was led by Edward Burns and Roger Kitain (both from Oracle). JSF 1.2 was not a JSR for new features. According to specification page, the primary goal of the JSR was handling the Faces side of the JSP/Faces alignment issues addressed in the parallel JSR-245 (JavaServer Pages 2.1). The specification contained also several secondary goals: enhancements to provide an interim solution to the content-interweaving problem described in article Improving JSF by Dumping JSP 3 ; provide XML Schema for the config files, instead of using DTD; enhancements to allow faces applications to handle multi-frame, or multi-window UI designs; enhancements to the f tag library for improved TCK coverage, <f:view> lifetime events, and other small features; enhancements to the decorator support for API objects; security enhancements for client side state saving; 1. JSR-127, 2. JSR-252, 3. Improving JSF by Dumping JSP, 4

12 2. THE JAVASERVER FACES FRAMEWORK solve the "duplicate button press" problem; re-organize the spec into normative, and non-normative sections, to make implementation easier; portlet related bug-fixes; and bug fixes that require minimal spec changes. In July 2009 JavaServer Faces 2.0 specification was released. 4 The specification was led, as JSF 1.2, by Edward Burns and Roger Kitain. Similarly to previous specifications, expert group consisted of several individuals and companies, such as Oracle, Sun Microsystems, Red Hat, Exadel, IBM, Apache Software Foundation and many other. Unlike JSF 1.2, 2.0 was a feature specification targeting the Java EE 6 Platform. According to specification page, the JSR was about to bring the best ideas in web application development to the Java EE platform. Specification should maximize the productivity of web application development and minimize the complexity of maintenance of the web application during its production lifetime. Another goal of the specification was to bring an easy to use API for Ajax. The technical details will be explained in following sections. This work will focus mainly on JSF 2.0 and upcoming versions. JSF applications need a JSF implementation to run. There are two major implementations of JSF: a reference implementation (also known as Mojarra) and Apache s implementation called MyFaces. All JEE 6 compliant application servers contain a JSF implementation, e.g. GlassFish V3 contains Mojarra and JBoss AS 6 contains both Mojarra and MyFaces. 2.2 Key Terms This section contains a list of key terms used in JSF as explained by Kito Mann in his book JavaServer Faces in Action [6, p ]. UI component is a stateful object, maintained on the server, that provides specific functionality for interacting with an end user. UI components are JavaBeans with properties, methods, and events. They are organized into a view, which is a tree of components usually displayed as a page. Renderer is responsible for displaying a UI component and translating a user s input into the component s value. Renderers can be designed to work with one or more UI components, and a UI component can be associated with many different renderers. Validator is responsible for ensuring that the value entered by a user is acceptable. One or more validators can be associated with a single UI component. 4. JSR-314, 5

13 2. THE JAVASERVER FACES FRAMEWORK Backing beans (managed beans) are specialized JavaBeans that collect values from UI components and implement event listener methods. They can also hold references to UI components. Converter converts a component s value to and from a string for display. A UI component can be associated with a single converter. JSF uses the JavaBeans event/listener model (also used by Swing). UI components (and other objects) generate events, and listeners can be registered to handle those events. Message is some information that is displayed back to the user. Just about any part of the application (backing beans, validators, converters, and so on) can generate information or error messages that can be displayed back to the user. Navigation is the ability to move from one page to the next. JSF has a powerful navigation system that is integrated with specialized event listeners. 2.3 JSF Application A JavaServer Faces application is like any other Java web application. A typical JSF application includes the following parts: [7, section 4] a set of web pages in which components are laid out; a set of tags to add components to the web page; a set of backing beans, which are JavaBeans 5 component that define properties and functions for components on a page; a web deployment descriptor (web.xml file); optionally, one or more application configuration files, such as a faces config.xml file, which can be used to define page navigation rules and configure beans and other custom objects, such as custom components; optionally, a set of custom objects, which can include custom components, validators, converters, or listeners, created by the application developer; and a set of custom tags for representing custom objects on the page. A simple web.xml descriptor might look like in the following code snippet where two URL patterns are mapped to Faces servlet. When running JSF 2.0 on a Servlet 3.0 container, the web.xml is optional. If no web.xml is found, the Faces Controller servlet is automatically mapped to the most popular URL patterns: /faces/*, *.jsf, and *.faces.[5, p. 9] 5. JavaBeans, 6

14 2. THE JAVASERVER FACES FRAMEWORK 1 <?xml version="1.0" encoding="utf-8"?> 2 <web-app version="2.5" xmlns=" 3 xmlns:xsi=" 4 xsi:schemalocation=" xml/ns/javaee/web-app_2_5.xsd"> 5 <display-name>foo Application</display-name> 6 <context-param> 7 <param-name>javax.faces.default_suffix</param-name> 8 <param-value>.xhtml</param-value> 9 </context-param> 10 <servlet> 11 <servlet-name>faces Servlet</servlet-name> 12 <servlet-class>javax.faces.webapp.facesservlet</servlet-class> 13 <load-on-startup>1</load-on-startup> 14 </servlet> 15 <servlet-mapping> 16 <servlet-name>faces Servlet</servlet-name> 17 <url-pattern>/faces/*</url-pattern> 18 </servlet-mapping> 19 <servlet-mapping> 20 <servlet-name>faces Servlet</servlet-name> 21 <url-pattern>*.jsf</url-pattern> 22 </servlet-mapping> 23 <welcome-file-list> 24 <welcome-file>faces/index.xhtml</welcome-file> 25 </welcome-file-list> 26 </web-app> Example of faces-config.xml: 1 <?xml version="1.0" encoding="utf-8"?> 2 <faces-config version="2.0" xmlns=" 3 xmlns:xi=" xmlns:xsi=" /2001/XMLSchema-instance" 4 xsi:schemalocation=" xml/ns/javaee/web-facesconfig_2_0.xsd"> 5 <application> 6 <locale-config> 7 <default-locale>en</default-locale> 8 <supported-locale>en</supported-locale> 9 </locale-config> 10 <message-bundle>com.pitonak.foo.messages</message-bundle> 11 </application> 12 </faces-config>f Both web.xml and faces-config.xml are located in WEB-INF directory. Once a JSF application is properly configured, XHTML pages can be constructed (notice the mixture of HTML and JSF tags). Here is example index.xhtml: 1 <html xmlns=" 2 xmlns:h=" 3 <h:head/> 4 <h:body> 7

15 2. THE JAVASERVER FACES FRAMEWORK 5 <h:form> 6 name: <h:inputtext value="#{foobean.name}"/> <br/> 7 Hello <h:outputtext value="#{foobean.name}"/>! <br/> 8 <h:commandbutton value="greet"/> 9 </h:form> 10 </h:body> 11 </h:head> A very minimalist managed bean might look as follows: 1 package com.pitonak.foo; 2 import javax.faces.bean.managedbean; 3 import javax.faces.bean.sessionscoped; 4 7 public class FooBean { 8 private String name; 9 10 public String getname() { 11 return name; 12 } public void setname(string name) { 15 this.name = name; 16 } 17 } 2.4 The Request Processing Lifecycle In the example presented in last section, a managed bean FooBean is named foobean. Its getter and setter methods are called using the Unified Expression Language. [7, section 6]. JSF creates and manages a server-side component tree in memory that directly corresponds to the components included in a page. [5, p. 10] Figure 2.1: JSF component tree 8

16 2. THE JAVASERVER FACES FRAMEWORK Common tasks, such as handling incoming requests, decoding parameters, modifying and saving state, and rendering web pages to the browser are all performed during a web application lifecycle. By default, JavaServer Faces automatically handles most of the lifecycle actions for a developer. However, it also exposes the various stages of the request lifecycle, so that developer can modify or perform different actions if his application requirements warrant it. [7, section 4] The lifecycle of a JavaServer Faces application starts and ends with the following activity: the client makes a request for the web page, and the server responds with the page. The whole request processing lifecycle is more complicated. JavaServer Faces goes through several phases when it processes a single incoming request: [6, p. 59] Restore View finds or creates a tree of components for the selected view; some components, like HtmlCommandButton, will generate action events (or other types of events) in this phase; Apply Request Values updates the value of the components to equal ones sent in the request, optionally using converters; adds conversion errors if there is an error and also generates events from request parameters; Process Validations asks each component to validate itself (which may include using external validators); validation error messages may be reported; Update Model Values updates all the values of backing beans or model objects associated with components; conversion error messages may be reported; Invoke Application calls any registered action listeners; the default action listener will also execute action methods referenced by command components and choose the next view to be displayed; and Render Response displays the selected view using the current display technology (like JSP). For the initial request, only the view is built which means that only phases Restore View, Invoke Application and Render Response are invoked. For subsequent (postback) requests, some or all other phases are invoked. In chapter 3 some advanced techniques for limiting the request processing lifecycle will be explained. When the application from previous section is built and deployed to an application server, the application is in an uninitiated state. When a client makes an initial request for index.xhtml web page, the Facelets application is compiled (see section The Facelets View Declaration Language). The compiled Facelets application is executed and a new component tree is constructed for the application and is placed in a FacesContext. The component tree is populated with the component and the backing bean property associated with it. Then a new view is built and rendered to the requesting client as a response. The component tree is destroyed automatically. On subsequent requests, the component tree is rebuilt and 9

17 2. THE JAVASERVER FACES FRAMEWORK Figure 2.2: Initial request vs. usual postback request the saved state is applied to it. 2.5 The Navigation Model Navigation happens in a web application when a user tries to switch from one page to another page. There are several ways how to navigate on the web application: 1. submitting a form and invoking an action method; 2. clicking a hyperlink; or 3. directly entering the target URL of a page into a browser. Whatever be the case, the next page to be displayed or the response for the current page has to be handled by the web application. The navigation outcome is result of an action method. In JSF 1.x all navigation cases had to be configured in faces-config.xml. For example, when navigating from page1 to page2 in response to a success outcome on a command compo- 10

18 nent in page1 required the following XML boilerplate code: [8] 1 <navigation-rule> 2 <from-view-id>/page1.xhtml</from-view-id> 3 <navigation-case> 4 <from-outcome>success</from-outcome> 5 <to-view-id>/page2.xhtml</to-view-id> 6 </navigation-case> 7 </navigation-rule> 2. THE JAVASERVER FACES FRAMEWORK The URL of the resulting page will be concatenation of context root, context path, Faces servlet mapping, and view ID, e.g. for the sample above the URL of the page might be JSF 2.0 introduced a simplification called implicit navigation that reduces the size of facesconfig.xml. If no matching navigation case is found, the navigation handler checks to see whether the outcome of action corresponds to a view ID. It is possible to use absolute path to the page (/page2.xhtml), relative path to the page (page2.xhtml) or even the ID of the view (page2). The sample action method called from page1 resulting in navigation to page2 might look like this: 1 public String fooaction() { 2 // some business logic 3 return "page2"; 4 } Another enhancement to the navigation subsystem is conditional navigation. It is possible to use expression language in pre-conditions that must be met in order for the navigation case to be accepted: 1 <navigation-rule> 2 <from-view-id>/page1.xhtml</from-view-id> 3 <navigation-case> 4 <from-outcome>success</from-outcome> 5 <to-view-id>/page2.xhtml</to-view-id> 6 <if>#{bean.foocondition}</if> 7 </navigation-case> 8 </navigation-rule> One of drawbacks of JSF navigation is that it uses strings for outcomes. Apache MyFaces Extensions project (CODI), inspired by Tapestry, brings type-safe navigation to the JSF 2 (using Contexts and Dependency Injection, JSR-299). Another implementation is Seam Faces. It is probable that type-safe navigation will be addressed in future version of JSF specification. There has to be a new class defined for each view and the action method returns a Class object instead of string: 1 public Class fooaction() { 2 // some business logic 3 return Page2.class; 4 } 11

19 2. THE JAVASERVER FACES FRAMEWORK 2.6 Managed Beans and Scopes Model objects in JSF are called managed beans. Section 2.3 showed how to define and use a simple managed bean. Managed beans are accessed from XHTML pages using Unified Expression Language (EL). 6 Any time user references a bean, Managed Bean Creation facility creates the bean, initializes it, and stores it in the proper application scope if it does not already exist. If the bean already exists, it is returned. [6, p. 110] In JSF 1.x, it was necessary to configure managed beans in the faces-config.xml: 1 <managed-bean> 2 <managed-bean-name>foobean</managed-bean-name> 3 <managed-bean-class>com.pitonak.foo.foobean</managed-bean-class> 4 <managed-bean-scope>session</managed-bean-scope> 5 </managed-bean> In JSF 2 it is possible to configure managed beans directly in code using annotations, for example see section 2.3. In JSF 2 it is possible to use the following scopes: request variables are available only during the current request; flash variables survive a single view transition, including surviving redirects; view variables are preserved until the user finishes interaction with the current view; session variables are available for during of user s HTTP session; application variables are available for the entire life of the application; and custom a scope defined by the user using EL expression instead of a keyword. Even though new scopes were added to JSF 2 (flash and view), it is still missing some commonly used scopes such as conversation known from JBoss Seam Framework. In Java EE 6 a new standard was created - Contexts and Dependency Injection (CDI, JSR-299). CDI defines four built-in scopes: request, session, application, and conversation. 7 It is recommended to use CDI for creating JSF 2 applications. 2.7 The Facelets View Declaration Language When JSF was created, JSP was about to be reused as it was already a standard in the web community. The idea was to simplify the adoption of JSF by using a familiar tag language. 6. Expression Language, html 7. CDI scopes, scopescontexts.html 12

20 2. THE JAVASERVER FACES FRAMEWORK Unfortunately, JSP and JSF do not naturally complement each other. JSP is not suitable for creating component trees. Its elements are processed in a page from top to bottom with the basic objective of creating a response to a request. On the other hand, JSF has a more complex life cycle, and thus mixing JSP and JSF tags in pages causes problems. Consider the following example: 1 <h:panelgroup> 2 <h:outputtext value="first"/> 3 second 4 </h:panelgroup> In the example above, JSF tags (h:panelgroups and h:outputtext) are mixed with JSP fragments (free text). This causes that the output of the example will be reversed: [9, p ] 1 second 2 first This is one of reasons why several view definition languages, such as Apache Shale s Clay, JSFTemplating or Facelets, were created. Bruno Aranda and Zubin Wadia describe Facelets as a templating language developed from the ground up with JavaServer Faces in mind. [10, foreword] Facelets is founded on the idea of compositions. This means that a component tree can be defined in multiple Facelet pages. A simple template can look like this (template.xhtml): 1 <html xmlns=" 2 <head> 3 <title><ui:insert name="title">default title</ui:insert></title> 4 <ui:insert name="head"/> 5 </head> 6 <body> 7 <ui:insert name="body"> 8 <p>body of the page.</p> 9 </ui:insert> 10 </body> 11 </html> Page using the defined template will then look like this (index.xhtml): 1 <html xmlns=" 2 <body> 3 <ui:composition template="/template.xhtml"> 4 <ui:define name="title">main page</ui:define> 5 <ui:define name="body"> 6 some content 7 </ui:define> 8 </ui:composition> 9 </body> 10 </html> 13

21 2. THE JAVASERVER FACES FRAMEWORK JSF 2.0 recognizes the need for a standard alternative to JSP. JSF 2 introduced a generic foundation for integrating view declaration languages into the JSF runtime environment the view declaration language API. This API allows framework authors to define their own view declaration languages and integrate these with JSF in a standard way. Moreover, Facelets became part of JSF 2.0 as default declaration language implementation. This 2.0 version of Facelets ought be very familiar to anyone who has been using Facelets 1.x. Most of the 1.x APIs are present, though there has been some tweaking/repackaging as part of the standardization process. [8] 2.8 Composite Components Creating a custom component in JSF is quite complicated process. In the worst case, a component class has to be created, with a lot of attributes with special getters and setters that interacts with StateHelper, renderer-specific class that contains similar attributes for parameters related to HTML and defines JSF behavior events for them. A renderer class that generates HTML code using spaghetti of startelement /writeattribute/writetext /endelement calls has to be created as well. Everything has to be described in the facesconfig.xml and Facelets taglib.xml has to be created. [11] RichFaces uses special Component Development Kit (CDK) that simplifies development of custom components and lets developers to concentrate on component functionality only. Even though RichFaces CDK is a powerful tool, it is too complicated for simple components. JSF 2 greatly simplifies custom component development with the introduction of the composite component feature. [8]. A simple Hello world component could be implemented with a single file with no Java code required (hello.xhtml): 1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2 " 3 <html xmlns=" 4 xmlns:h=" 5 xmlns:composite=" 6 <h:body> 7 8 <composite:interface> 9 <composite:attribute name="who"/> 10 </composite:interface> <composite:implementation> 13 <h:outputtext value="hello, #{cc.attrs.who}!"/> 14 </composite:implementation> </h:body> 17 </html> This is how the component would be used on a page: 14

22 2. THE JAVASERVER FACES FRAMEWORK 1 <html xmlns=" 2 xmlns:h=" 3 xmlns:greet=" 4 <h:head/> 5 <h:body> 6 <greet:hello who="world"/> 7 </h:body> 8 </html> 2.9 Resource Handling Before JSF 2 each component library loaded resources (images, JavaScript files, style sheets, etc.) in its own way. JSF 2 provides a standard solution to resource loading with the introduction of the resource handler API. The ResourceHandler is responsible for serving up resources from well-known locations on the class path. Resource requests are routed through the FacesServlet, which passes these request onto the ResourceHandler for processing. This solution allows components and their resource dependencies to be bundled in the same jar file with no need for a bonus servlet, servlet filter or phase listener to serve up these artifacts. In order to support resource relocation, JSF 2 introduces two new tags: <h:head> and <h:body>. These components render the HTML head/body markup and also provide a target for relocatable resources. [8] 2.10 Component Libraries JSF provides a basic set of components for creating web pages such as inputs, outputs, tables, etc. However, modern web applications require more advanced components, such as inplace inputs, tables with sortable columns, pagination in tables, various menus and panels, progress bars, charts and more. This is a reason why many components libraries were created. This thesis will describe four open source libraries RichFaces, PrimeFaces, Open- Faces, and ICEfaces. RichFaces RichFaces is a JSF component framework containing tens of advanced visual and non-visual components. JSF 2 s <f:ajax> tag was inspired by RichFaces <a4j:support> tag which will be described in detail in section 3.1. RichFaces is a project created by Alexander Smirnov. In 2005, Smirnov was hired by Exadel and continued to develop the framework (then called Ajax4jsf). In 2007 Red Hat and Exadel signed a partnership agreement. RichFaces were open sourced under the GNU Lesser General Public License, version 2.1 and became a JBoss.org project. 15

23 2. THE JAVASERVER FACES FRAMEWORK The main features of RichFaces include advanced Ajax components, many visual component, strong skinning support, client side validation and a component development kit (CDK). In the sample application developed for this thesis (will be described later), version SNAPSHOT of RichFaces is used. Unlike RichFaces 3, client-side code in RichFaces 4 is implemented in jquery only. RichFaces 4 support this environments: Java Development Kit (JDK) 1.5 or higher; an application server compliant with JEE6, such as JBoss Application Server 6 or Glassfish 3; servlet containers Tomcat 6 or 7; Google App Engine; JSF 2 implementation such as Mojarra or Apache MyFaces 2.0.4; and web browser such as Google Chrome 11, Firefox 3.6, or Internet Explorer 8. PrimeFaces PrimeFaces is a lightweight open source (Apache License v2) component suite for JSF 2 featuring more than 100 of JSF components. Additional PrimeFaces Mobile module features a UI kit for developing mobile web applications. However, development of mobile web applications is out of the scope of this work and therefore this part of PrimeFaces will not be described. PrimeFaces is maintained by Prime Technology, a Turkish software development company specialized in agile consulting, JSF, Java EE and outsourcing. Project is led by Çağatay Çivici. The sample application uses PrimeFaces which support similar environments as RichFaces. OpenFaces OpenFaces is an open-source library of Ajax-powered JSF components, an Ajax framework and a client-side validation framework. OpenFaces is based on the set of JSF components formerly known as QuipuKit. It contains fully revised codebase of QuipuKit and introduces many new components and features. OpenFaces is distributed under a dual license model. Users can choose between using the library under GNU Lesser General Public License v2.1 or purchasing a commercial license. OpenFaces is contributed and administered by TeamDev Ltd, and Ukrainian company providing Java development services. The sample application uses OpenFaces 3.0 which supports very similar environments as Rich- Faces. 16

24 2. THE JAVASERVER FACES FRAMEWORK ICEfaces ICEfaces 2 is an open source (Mozilla Public License) rich Internet application development framework based on the JavaServer Faces 2 standard. Like its predecessor, ICEfaces 1.8, ICEfaces 2 extends JSF to simplify development and enhance the standard JSF feature set simultaneously improving developer efficiency and expanding the spectrum of RIA capabilities that can be included in any JSF-based web application. Adhering closely to the standard JSF 2 extension points allows ICEfaces to work transparently with the stock JSF framework, simplifying integration and fostering 3rd party compatibility with other JSF 2-compliant libraries. The two most significant features of ICEfaces 2 are automatic Ajax with Direct-to-DOM rendering and Ajax Push (see chapter 3). ICEfaces 2 contains three sets of components: 1. ICEfaces Components original components from ICEfaces 1.8 using a compatibility layer that enables them to work with JSF 2; 2. ICEfaces Advanced Components using all the features of the JSF 2 standard and are based on a new Advanced Component Environment; and 3. ICEfaces Enterprise Components derived from ICEfaces 1.8 composite components but ported to Facelets, these components are available only in ICEfaces 2 Enterprise Edition. Since this thesis deals only with freely available open source components, the ICEfaces Enterprise Components will not be compared. The sample application uses ICEfaces which runs on JBoss AS 6, Glassfish 3.1 and all modern web browsers. Moreover, it runs in Liferay Portal [12] There are many other open source JSF component libraries. In 2006 Oracle donated its Oracle ADF Faces to the Apache Software Foundation which became MyFaces Trinidad. Other examples are MyFaces Tobago (donated by Atanion GmbH) and MyFaces Tomahawk. There are also many proprietary technologies built on JSF, such as IBM s XPages. Though, all these technologies are out of the scope of this work. 17

25 3 Ajax and Core Components 3.1 Ajax in JSF 2 and in Component Libraries One of major additions to the JSF 2 is standard Ajax support. In JSF 1.2 every component framework implemented Ajax in it own style. On the client side, JSF 2 exposes a new JavaScript API that issues an Ajax request back to the current view. Once the request enters the Faces lifecycle, the state of the Ajax request is captured via the PartialViewContext. This object provides access to information such as which components are targeted for processing/rendering. The PartialViewContext s processpartial() method uses this information to perform partial subtree processing/rendering. When the rendered response is sent back to the client, the callback previously provided by jsf.ajax.request() is invoked. This callback automatically updates the client-side DOM to reflect the newly rendered markup. [8] The jsf.ajax.request() JavaScript API is targeted for use by frameworks as well as by the JSF implementation itself. JSF 2 also includes a declarative approach using the new <f:ajax> tag. The tag was inspired by tag <a4j:support> tag from RichFaces 3: 1 <h:form> 2 <h:inputtext id="input" value="#{bean.text}" > 3 <a4j:support event="keyup" process="input" rerender="output"/> 4 </h:inputtext> 5 <h:outputtext id="output" value="#{bean.text}" /> 6 </h:form> 1 <h:form> 2 <h:inputtext id="input" value="#{bean.text}" > 3 <f:ajax event="keyup" execute="input" render="output"/> 4 </h:inputtext> 5 <h:outputtext id="output" value="#{bean.text}" /> 6 </h:form> The first sample demonstrates the use of RichFaces 3 <a4j:support> tag. When a user starts typing into input, pressed keys are sent by Ajax to the server, bean is updated and then output is rerendered. Attribute execute says the server which data should be process and attribute rerender says the client which parts of the page should be rerendered. The second sample does exactly the same but it uses JSF 2 to send Ajax request. Since it was inspired by RichFaces 3, the usage is almost the same. RichFaces 4 comes with its own tag, <a4j:ajax>, which is based on f:ajax but upgrades the tag with more features and advanced functionality. It originates in <a4j:support> but was greatly refactored in order to be similar to <f:ajax>. The previous example written using RichFaces 4 would look very similarly: 1 <h:form> 18

26 3. AJAX AND CORE COMPONENTS 2 <h:inputtext id="input" value="#{bean.text}" > 3 <a4j:ajax event="keyup" execute="input" render="output"/> 4 </h:inputtext> 5 <h:outputtext id="output" value="#{bean.text}" /> 6 </h:form> Max Katz describes non-standard features of <a4j:ajax>. [13] First of all, EL expressions in render and execute attributes are evaluated differently and <a4j:ajax> accepts a special which instructs the application to execute/render only <a4j: region>. Secondly, it adds new event handlers: onbegin JavaScript to execute before Ajax request; onbeforedomupdate JavaScript to execute after response comes back but before any DOM update; and oncomplete JavaScript to execute after response comes back but before any DOM update. Last but not least important attribute is bypassupdate which, if set to true, skips Update Model and Invoke Application phases which is useful for form validation. PrimeFaces contain <p:ajax> tag that is very similar to RichFaces <a4j:ajax>. However, there are some little differences. First, <p:ajax> has attribute process instead of standard execute and attribute update instead of standard render. PrimeFaces Ajax tag has additional event handlers similar to those in <a4j:ajax> onstart, oncomplete, and onsuccess. OpenFaces contain their own tag for Ajax, too. Similarly to RichFaces and PrimeFaces, it contains additional event handlers onajaxstart and onajaxend. Moreover, it has attribute delay that reduces the number of Ajax requests by skipping the frequently-happening events. This attribute specifies the delay in milliseconds that should elapse after an event that activates this component to start an actual request for reloading components (and invoking an appropriate action if specified). If there will be another event during this delay, this event will postpone the request according to the specified delay instead of performing an additional request. As a result there will be only one request for all events that come more frequently than specified in this attribute. Exactly the same behavior can be implemented in RichFaces by using queues (see section 3.5). Another interesting feature of <o:ajax> is its attribute for which allows attaching Ajax component to an arbitrary component or HTML tag instead of attaching to the parent component. The sample above might look in Open- Faces as follows: 1 <h:form> 2 <h:inputtext id="input" value="#{bean.text}" /> 3 <o:ajax for=":input" event="keyup" execute="input" render="output"/> 4 <h:outputtext id="output" value="#{bean.text}" /> 5 </h:form> 19

27 3. AJAX AND CORE COMPONENTS ICEfaces use a very different approach to Ajax called automatic Ajax. ICEfaces Automatic Ajax feature guarantees minimal page updates under any condition, and does not require the page developer to consider how, when or why page updates occur. The key to Automatic Ajax is the use of Direct-to-DOM (D2D) rendering in the ICEfaces framework. D2D does just what it says, and writes the output of the JSF rendering phase into a server-side DOM that represents exactly what the client DOM needs be. Using a cached version of the DOM, the framework calculates precisely the set of DOM updates required to affect the changes in the page at the completion of any JSF lifecycle. [14, section Automatic Ajax] Although the D2D handles the page updating aspect, it is still necessary to initiate the whole process through some UI event. ICEfaces provides the Single Submit features, which causes a component to submit itself automatically when the user interacts with it. 1 <h:form> 2 <icecore:singlesubmit/> 3 <h:inputtext id="myinput" value="#{bean.input}"/> 4 output: <h:outputtext id="output" value="#{bean.input}"/> 5 </h:form> On one hand, the automatic Ajax feature optimizes the development time but on the other hand, there is some overhead as it is necessary to render the entire page to produce the DOM for comparison. This can be optimized by using <f:ajax> tag with redefined attribute render. 1 <h:form> 2 <icecore:singlesubmit/> 3 <h:inputtext id="myinput" value="#{bean.input}"> 4 <f:ajax execute="@this" render="output"/> 5 </h:inputtext> 6 output: <h:outputtext id="output" value="#{bean.input}"/> 7 </h:form> More information about both automatic Ajax and Direct-to-DOM rendering can be found in ICEfaces documentation. [14, section Direct-to-DOM] 3.2 Region RichFaces contain an <a4j:region> component which specifies a part of the JSF component tree to be processed on the server. The region causes all the a4j and rich Ajax controls to execute: decoding, validating, and updating the model. The region causes these components to execute even if not explicitly declared. As such, processing areas can more easily be marked using a declarative approach. Regions can be nested, in which case only the parent region of the component initiating the request will be processed. [15, section a4j:region] 20

28 3. AJAX AND CORE COMPONENTS There is no region component in other component libraries. However, because of ICEfaces automatic Ajax and Direct-to-DOM rendering, it is not needed when using ICEfaces. 3.3 Command Button and Command Link RichFaces <a4j:commandbutton> and <a4j:commandlink> components are similar to the JavaServer Faces <h:commandbutton> and <h:commandlink> components, but additionally include Ajax support. All extra attributes from <a4j:ajax>, e.g. onbegin or bypassupdates, are also available in command button and command link. Similarly to RichFaces, PrimeFaces command button and command link are very similar to standard JSF button and link but add advanced features that are available also in the component <p:ajax>. What is unique comparing to RichFaces, <p:commandbutton> and <p:commandlink> have attribute ajax which specifies submit mode when set to true (default), submit would be made with Ajax. OpenFaces link extends standard JSF link, too, and add some features from <o:ajax>. OpenFaces button is more advanced because it supports child elements inside and so it is possible to create graphical images with text: 1 <o:commandbutton action="#{foobean.bar}"...> 2 <h:graphicimage url="..."/> 3 <h:outputtext value="..."/> 4 </o:commandbutton> ICEfaces contain command button and command link component that are very similar to those in RichFaces. Figure 3.1: Command button in RichFaces, PrimeFaces, OpenFaces, and ICEfaces 3.4 JavaScript Function If a user need to fire an Ajax request from his JavaScript function, it is possible to directly call jsf.ajax.request(), RichFaces.ajax() or similar functions from PrimeFaces and OpenFaces. However, this approach is error prone and therefore RichFaces contains the component <a4j:jsfunction> which performs Ajax requests directly from JavaScript code and retrieves server-side data. The server-side data is returned in JavaScript Object 21

29 3. AJAX AND CORE COMPONENTS Notation (JSON) format prior to the execution of any JavaScript code defined using the oncomplete attribute. 1 <a4j:jsfunction name="updatename" render="showname"> 2 <a4j:param name="name" assignto="#{functionbean.text}"/> 3 </a4j:jsfunction> 4 5 <span onmouseover="updatename( Kate )" onmouseout="updatename( )"> 6 Kate 7 </span> 8 <h:outputtext id="showname" value="#{functionbean.text}" /> OpenFaces component <o:ajax> has attribute standalone which behaves similarly to <a4j:jsfunction>. In is used in this way: 1 <h:form id="form"> 2 <h:inputtext id="textfield" 3 onkeypress="o$( form:updateimage ).run()".../> 4 <o:ajax id="updateimage" standalone="true" render="dynamicimage" 5 execute="textfield colorfield fontsizefield" requestdelay="500"/> 6 <o:dynamicimage id="dynamicimage".../> 7 </h:form> There is not any similar component in PrimeFaces nor ICEfaces. 3.5 Queue JSF 2 has very basic queue functionality requests are queued and fired one at a time. This means that only one request is processed on the server at a time. Since it is a very simple queue, RichFaces implemented a much more sophisticated queue. The component <a4j :queue> provides additional options for a finer control of request processing. It works in the same basic way as the standard JSF queue. It can be enabled and disabled through the enabled attribute. Attribute requestdelay adds a delay between each request in the queue. Delaying requests avoids unnecessary processing for actions that would otherwise cause multiple requests, such as typing. Similar requests in the queue are combined while waiting for the request delay. The user ought be aware of the fact that the component does not handle standard JSF requests or requests from component libraries other than Rich- Faces. [15, section a4j:queue] RichFaces contains behavior <a4j:attachqueue> which is used together with component <a4j:queue> to further customize queuing for particular components and behaviors. The <a4j:attachqueue> behavior can override the scope-wide queue settings for an individual component, or attach specific requests to a queue. 1 <a4j:queue requestdelay="2000"/> 2 3 <h:form> 22

30 3. AJAX AND CORE COMPONENTS 4 <h:inputtext> 5 <a4j:ajax event="keyup" /> 6 </h:inputtext> 7 <a4j:commandbutton value="submit"> 8 <a4j:attachqueue requestdelay="0" /> 9 </a4j:commandbutton> 10 </h:form> PrimeFaces do not have any queue component. In OpenFaces, it is possible to set attribute delay of <o:ajax> which has similar functionality. 3.6 Status Users of a web page usually want to know the status of latest action they triggered. This is the place where status component is useful. RichFaces contain a highly customizable component <a4j:status> which can be in three states: progress during the execution of an Ajax request; complete after an Ajax request completed successfully; or error after and Ajax request completed with an error. It is possible to define start text, stop text and error text. User can choose whether component s attributes or facets will be used. 1 <a4j:status id="status1" starttext="work in progress..." 2 stoptext="complete" errortext="error"> 3 4 <a4j:status id="status2"> 5 <f:facet name="start"> 6 <h:graphicimage value="/images/ai.gif" alt="ai"/> 7 </f:facet> 8 <f:facet name="stop">...</f:facet> 9 <f:facet name="error">...</f:facet> 10 </a4j:status> The <a4j:status> component monitors the status of the region relevant to where it is placed. If it is unnamed and placed outside any forms, it monitors the status at the view level. If unnamed and placed inside a form, it monitors the status at the form level. [15, section a4j:status] PrimeFaces contains a similar component called <p:ajaxstatus>. Unlike RichFaces status, it is not possible to define start text, stop text, etc. using attributes. On the other hand, it has more facets so it is possible to customize the component a bit better. Its list of facets include prestart, start, complete, error, and success. Similarly to <a4j:status>, it is possible to define whichever markup the user needs in facets. 23

31 3. AJAX AND CORE COMPONENTS In OpenFaces, the status of current request is handled in different way. When any Ajax request is in progress, the Loading... message with and animated image appear in the upper-right corner of the screen. This message is displayed by default. It is possible to configure this message for the whole application or for the particular page. The user can change the Ajax progress message for the whole application by specifying the org.openfaces. ajaxmessagehtml parameter in web.xml. This parameter should be specified as portion of HTML that will be shown in the upper-right corner on an Ajax request. [16, section Ajax Settings Component] 1 <context-param> 2 <param-name>org.openfaces.ajaxmessagehtml</param-name> 3 <param-value><![cdata[ 4 <div style="background: white; font: Tahoma 15pt normal; border: 1px solid black;"> 5 <img src="/resources/images/progress.gif"/> 6 Ajax request is currently in progress! 7 </div> 8 ]]></param-value> 9 </context-param> When the user needs to change the status only for a particular page, the progressmessage facet of the <o:ajaxsettings> tag which accepts tag <o:defaultprogressmessage> should be used. It provides many options for customization, such as text, image URL, alignment, transparency and many more. It is also possible to define mode which tells OpenFaces whether to display message for all Ajax requests or only for those fired by OpenFaces components. Sample configuration would look like this: 1 <o:ajaxsettings> 2 <f:facet name="progressmessage"> 3 <o:defaultprogressmessage text="..." imageurl="..." 4 mode="..." transparency="..." > 5 </f:facet> 6 </o:ajaxsettings> RichFaces and OpenFaces interoperate in this field very nice. When an OpenFaces component fires an Ajax request, RichFaces status component shows the progress and vice versa. PrimeFaces status, unlike RichFaces and OpenFaces, can handle only requests from Prime- Faces components. RichFaces and OpenFaces cannot handle PrimeFaces requests, too. The <a4j:status> components cannot be present on the page when using ICEfaces. Otherwise, the Ajax request is fired and the page is updated but the <a4j:status> never shows the end of request. This causes that all subsequent requests are blocked. There is the <ice:outputconnectionstatus> component that shows the progress of an Ajax request. However, it does not work for standard JSF requests, only those made by ICEfaces automatic Ajax. If no attributes are set, an image is displayed in each state. 1 <link rel="stylesheet" type="text/css" 2 href="./xmlhttp/css/xp/xp.css"/> 24

32 3. AJAX AND CORE COMPONENTS 3 <ice:outputconnectionstatus/> Figure 3.2: ICEfaces status in all states in two themes 3.7 Poll Poll is a component that has the ability to send periodical Ajax requests and execute action listener on a JSF managed bean. RichFaces poll has all standard Ajax attributes, such as onbegin, render, execute, etc., but the most important attribute is interval which is poll-specific. It specifies the time in milliseconds between requests. There is a very similar component in PrimeFaces. It also defines attributes usual for Prime- Faces components firing Ajax requests. The most noticeable difference from RichFaces poll is that attribute interval accepts an integer expressing the number of seconds, not milliseconds. There is no component with similar functionality in OpenFaces. ICEfaces contain poll component only in Enterprise Edition. 3.8 Push The push component performs real-time updates on the client side from events raised at the server side, e.g. displaying new messages in a chat application. Push behavior can be simulated using poll technique but it in most cases produces too much network traffic. Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. [17, p. 1]. There are several techniques how to achieve this, including long polling and HTTP streaming. When using long polling, browser s requests are suspended and only resumed when server decides to push data. After the response is retrieved, browser connects and begins to waiting for data again. An application using streaming Comet opens a single persistent connection from the client browser to the server for all Comet events. These events are incrementally handled and interpreted on the client side every time the server sends a new event, with neither side closing the connection. [18] 25

33 3. AJAX AND CORE COMPONENTS More modern approach to dealing with push in web applications is using WebSockets. Web- Sockets is a technology providing bi-directional, full-duplex communication channels, over a single Transmission Control Protocol (TCP) socket. It is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket specification developed as part of the HTML5 initiative introduced the Web- Socket JavaScript interface. The WebSocket API is being standardized by the W3C, and the WebSocket protocol is being standardized by the IETF. Because ordinary TCP connections to ports other than 80 are frequently blocked by administrators outside of home environments, it can be used as a way to overcome these restrictions and provide similar functionality with some additional protocol overhead while multiplexing several WebSocket services over a single TCP port. The WebSocket standard simplifies much of the complexity around bidirectional web communication and reduces network traffic significantly. Both RichFaces and PrimeFaces use the Atmosphere framework which implements both Comet and WebSockets and runs on any Java based web server including Tomcat, JBoss AS, Glassfish and many more. For the client side, WebSocket was to be implemented in Firefox 4, Google Chrome 4, Opera 11, and Safari 5, as well as the mobile version of Safari in ios 4.2. However, although present, support was disabled by default in Firefox 4 [19] and Opera 11 [20] because of concerns over security vulnerabilities. [21] Although the problem in WebSockets was already solved, it is expected that web browsers will implement the new version of protocol in next major releases. This would mean that all major browsers should have WebSockets enabled again in summer RichFaces push component performs real-time updates on the client side from events raised at the server side. The events are pushed out to the client through the Java Message Service (JMS). Instead of implementing its own messaging mechanism, RichFaces reuses the well defined and tested standard solution. This results in very easy integration of <a4j:push> with existing enterprise applications. On the other hand, for smaller applications not using Java EE compliant application server, it brings some overhead. When the <a4j:push> component is triggered by a server event, it can in turn cause Ajax updates and changes. The <a4j:push> component uses the Comet model for pushing data to the client. On the server side, RichFaces push first needs to initialize topics context, get and instance of TopicsContext and then send the message (the sample assumes that the JMS topic is configured in application server): 1 public void initializepush() { 2 TopicsContext topicscontext = TopicsContext.lookup(); 3 Topic topic = topicscontext.getorcreatetopic( 4 new TopicKey("fooTopic", "foosubtopic")); 5 topic.setmessagedataserializer( 6 DefaultMessageDataSerializer.instance()); 7 } 8 9 public void send() { 10 try { 26

34 3. AJAX AND CORE COMPONENTS 11 TopicsContext.lookup().publish( 12 new TopicKey("fooTopic", "foosubtopic"), message); 13 } catch (MessageException messageexception) { } 16 } On client, <a4j:push> tag would be used like this: 1 <a4j:push address="foosubtopic@footopic" 2 onerror="alert( Error: + event.rf.data)" 3 ondataavailable="handlepush(event.rf.data)"/> Ajax Push in ICEfaces 2.0 leverages an asynchronous notification mechanism called ICEpush. ICEpush unleashes the power of Ajax Push in a wide range of Java and JavaScript technologies, including JSP, JSF, Spring MVC, GWT, Wicket, jquery, and Prototype. ICEpush uses long polling to provide asynchronous notification over standard HTTP, using only standard browser capabilities. The sequence of events involved in ICEfaces Ajax Push is following: [14, section Ajax Push Overview] 1. some state change in the application triggers an Ajax Push event; 2. ICEpush notification is delivered to the browser client over a dedicated ICEpush connection; 3. notification at client browser causes a JSF Ajax request with an empty execute phase; and 4. render phase captures new state of client, and Direct-to-DOM Rendering delivers incremental page updates to client. ICEpush relies on Servlet 3.0 standard Asynchronous Request Processing APIs. If they are not present in the deployment environment, normal thread blocking connections are used. For clustered and high-availability deployments of Ajax Push-enabled applications the Enterprise Push Server (EPS) is required. It manages asynchronous blocking connections across the cluster and performs seamless fail over for mission-critical, high-availability deployments. EPS is available in ICEfaces Enterprise Edition. To use the ICEfaces push in application, client session has to be added to a push group: 1 PushRenderer.addCurrentSession("fooGroup"); Then, an Ajax Push notification ought be sent to any other client sessions in the push group foogroup. To do so, method PushRenderer.render() has to be called. 1 public String myaction() { 2 // some business logic 3 PushRenderer.render("fooGroup"); 27

35 3. AJAX AND CORE COMPONENTS 4 return null; 5 } ICEfaces push in version does not work properly because of an issue with asynchronous request processing (see ICEfaces Jira PUSH ). The issue is scheduled to be fixed in ICEfaces 2.1. PrimeFaces Push is powered by Atmosphere, however it is only compatible with version 0.5.x, not the newer one which is used by RichFaces push. To use <p:push>, the Comet Servlet and its mapping has to be defined in web.xml: 1 <servlet> 2 <servlet-name>comet Servlet</servlet-name> 3 <servlet-class>org.primefaces.comet.primefacescometservlet</servlet-class> 4 <async-supported>true</async-supported> 5 </servlet> 6 <servlet-mapping> 7 <servlet-name>comet Servlet</servlet-name> 8 <url-pattern>/primefaces_comet/*</url-pattern> 9 </servlet-mapping> On the server side, the following method is the main element of PrimeFaces Push. 1 CometContext.push(String channel, Object data) On the client side, the component <p:push> is used. This component has two main parameters channel and onpublish. The channel attribute represents an unique name of communication channel and onpublish attribute points to a JavaScript handler method. Published object is serialized as JSON, passed to publish handler, and is accessible using response.data. 1 <h:head> 2 <script type="text/javascript"> 3 function handlepublish(response) { 4 alert(response.data); 5 } 6 </script> 7 </h:head> 8 9 <h:body> 10 <h:form> 11 <h:inputtext value="..."/> 12 <p:commandbutton value="send" actionlistener="..."/> 13 </h:form> 14 <p:push channel="chat" onpublish="handlepublish"/> 15 </h:body> There is no push component in OpenFaces. 1. PUSH-128: Servlet 3.0 s ARP support is broken on Tomcat 7, PUSH

36 4 Input Components 4.1 Calendar Applications frequently require users to insert a date such as date of birth or the start date of employment. The <rich:calendar> component allows the user to enter a date and time through an inline or popup calendar. The popup calendar can navigate through months and years, and its look and feel can be highly customized. Figure 4.1: RichFaces calendar in popup mode expanded, in inline mode, and with hidden input Simple usage of <rich:calendar> migh look like in the following sample. RichFaces calendar works fine with all <f:ajax>, <a4j:ajax>, <p:ajax> and <o:ajax>. 1 <rich:calendar value="#{bean.datetest}" > 2 <a4j:ajax event="change".../> 3 </rich:calendar> In ICEfaces, there is the <ice:selectinputdate> component which renders either inline or popup calendar depending on attribute renderaspopup. Users may enter a date directly into the text input or click the popup button beside the input to display the popup calendar view (when in popup mode). When the attached <f:convertdatetime> is configured to show time, the calendar will include a time editing UI. 1 <ice:selectinputdate id="calendar" value="#{bean.date}"> 2 <f:convertdatetime pattern="mm/dd/yyyy hh:mm a" 3 timezone="#{bean.timezone}"/> 4 </ice:selectinputdate> OpenFaces contain two components for inputting dates calendar and date chooser. Open- Faces calendar component is an inline component and date chooser has an input and popup 29

37 4. INPUT COMPONENTS which contains <o:calendar>. Figure 4.2: Expanded OpenFaces date chooser and calendar In PrimeFaces, there is a <p:calendar> component. Like RichFaces calendar, it supports both inline and popup mode with or without icon. Figure 4.3: PrimeFaces calendar in inline mode, default popup mode and popup mode activated by clicking on button It has very similar features to RichFaces calendar. However, there is one unique feature paging. Using attribute pages it is possible to display multiple months at once. Figure 4.4: PrimeFaces calendar with pages attributes set to 3 All above mentioned calendar components can be easily localized so that users can input dates in the format to which they are used, names of months are in the language of theirs choice and week begins on Sunday or Monday according to set locale. All calendar components support only Gregorian calendar. It would not be easy to use e.g. Hebrew or Islamic 30

38 4. INPUT COMPONENTS calendar in JSF components. 4.2 Inplace Inputs An inplace input component allows information to be entered inline in blocks of text, improving readability of the text. RichFaces inplace input has three functional states: the view state, where the component displays its initial setting, such as click to edit ; the edit state, where the user can input text; and the changed state, where the new value for the component has been confirmed but can be edited again if required. It is possible to set the component to save its state on blur event and to display controls for confirming or canceling user s input. The second similar component provided by RichFaces is <rich:inplaceselect>. It looks the same in initial state but it renders a select menu instead of text input when in edit state. Basic inplace input and inplace select are very easy to use: 1 <rich:inplaceinput value="#{bean.value}" 2 defaultlabel="click here to edit"/> 3 4 <rich:inplaceselect value="#{bean.value2}" 5 defaultlabel="click here to edit" > 6 <f:selectitems value="#{bean.selectitems}" /> 7 <f:selectitem itemvalue="1" itemlabel="item 1" /> 8 <f:selectitem itemvalue="2" itemlabel="item 2" /> 9 <f:selectitem itemvalue="3" itemlabel="item 3" /> 10 <f:selectitem itemvalue="4" itemlabel="item 4" /> 11 </rich:inplaceselect> PrimeFaces contains a more universal component called <p:inplace>. It wraps not only text input but it is possible to create an inplace select, inplace checkbox or even inplace image. Inplace with inner <h:textinput> produces a component very similar to component <rich:inplaceinput>. However, with default settings, it does not behave the same the component does not save its state on blur event. On the other hand, it can be in editor mode when it shows buttons for confirming or canceling the input and then it is possible to fire Ajax requests. This advanced inplace would be used like this: 1 <p:inplace editor="true" oneditupdate="msgs"> 2 <p:inputtext value="#{inplacebean.text}" 3 required="true" label="text"/> 4 </p:inplace> Neither OpenFaces nor ICEfaces have inplace components. 4.3 Autocomplete Users of modern web applications expect inputs to show suggestions as they type into input. The <rich:autocomplete> component is an auto-completing input box with built-in 31

39 4. INPUT COMPONENTS Figure 4.5: RichFaces and PrimeFaces inplace input in initial state, in edit state and in edit state with controls enabled Ajax capabilities. It supports client-side suggestions, browser-like selection, and customization of the look and feel. To use the component, it is necessary to implement a method that will return list of suggestions, e.g.: 1 public List<String> autocomplete(string prefix) { 2 ArrayList<String> result = new ArrayList<String>(); 3 if (prefix!= null && prefix.length() > 0) { 4 Iterator<Capital> iterator = capitals.iterator(); 5 while (iterator.hasnext()) { 6 Capital elem = ((Capital) iterator.next()); 7 if ((elem.getstate()!= null && elem.getstate().tolowercase().indexof( prefix.tolowercase()) == 0) "".equals(prefix)) { 8 result.add(elem.getstate()); 9 } 10 } 11 } else { 12 for (Capital capital : capitals) { 13 result.add(capital.getstate()); 14 } 15 } 16 return result; 17 } This method will be set in autocompletmethod attribute of the <rich:autocomplet> component. 1 <rich:autocomplete autocompletemethod="#{bean.autocomplete}" 2 value="#{bean.value}"> The <rich:autocomplete> can work in several modes which influence if the data should be pre-loaded or if they will be fetched with an Ajax request on every user s input. By default, the first suggestion item is selected as the user types. This behavior can be deactivated by setting selectfirst to false. Setting autofill to true causes the combo-box to fill the text field box with a matching suggestion as the user types. The attribute tokens can be used for user to be able to input multiple values. For example, if the tokens attribute is set to,, 32

40 4. INPUT COMPONENTS user can use both comma and space for separating inputs. For each input, a new suggestion is process begins. PrimeFaces autocomplete component is very similar to RichFaces one. It can be used in almost the same way. There is attribute completemethod instead of RichFaces method autocompletemethod. This attribute can be bound to the method from RichFaces example without any changes. 1 <p:autocomplete completemethod="#{bean.complete}" 2 value="#{bean.value}"> It is possible to limit the maximum number of suggestions, set minimum query length and even set query delay in order to ensure that the server will not be flooded with Ajax requests. Instead of waiting for user to send the input manually with some action button or link, it is possible to send value of <p:autocomplete> instantly with Ajax. However, PrimeFaces do not support standard JSF way, i.e. to attach an Ajax behavior (<f:ajax>, <p:ajax>, or <a4j:ajax>). To do Ajax request, one has to set attribute selectlistener. Optionally, some parts of the page can be rerendered after selection using onselectupdate option. In OpenFaces, an autocomplete input component is called <o:suggestionfield>. It can contain static options (similarly to <h:selectonemenu>) or dynamic options. To use the later, the autocomplete method from above example has to be modified slightly: 1 public List<String> getcapitals() { 2 String prefix = Faces.var("searchField", String.class); 3 ArrayList<String> result = new ArrayList<String>(); 4 if (prefix!= null && prefix.length() > 0) { 5 Iterator<Capital> iterator = capitals.iterator(); 6 while (iterator.hasnext()) { 7 Capital elem = ((Capital) iterator.next()); 8 if ((elem.getstate()!= null && elem.getstate().tolowercase().indexof( prefix.tolowercase()) == 0) "".equals(prefix)) { 9 result.add(elem.getstate()); 10 } 11 } 12 } else { 13 for (Capital capital : capitals) { 14 result.add(capital.getstate()); 15 } 16 } 17 return result; 18 } Component will then be used in the following way: 1 <o:suggestionfield id="suggestionfield" value="#{osuggestionfieldbean.value}" 2 suggestionmode="custom"> 33

41 3 <o:dropdownitems value="#{osuggestionfieldbean.capitals}"/> 4 <o:ajax event="change" render="output"/> 5 </o:suggestionfield> 4. INPUT COMPONENTS Autocomplete in ICEfaces is represented by the <ice:selectinputtext> component. The usage is very similar to previous components. The filtering method can be reused with very small change. 1 <ice:selectinputtext rows="15" width="300" valuechangelistener="#{bean. updatelist}" 2 value="#{bean.selected}"> 3 <f:selectitems value="#{bean.list}" /> 4 </ice:selectinputtext> 1 public void updatelist(valuechangeevent event) { 2 matcheslist = new ArrayList<String>(); 3 String prefix = (String) event.getnewvalue(); 4 if (prefix!= null && prefix.length() > 0) { 5 Iterator<Capital> iterator = capitals.iterator(); 6 while (iterator.hasnext()) { 7 Capital elem = ((Capital) iterator.next()); 8 if ((elem.getstate()!= null && elem.getstate().tolowercase().indexof( prefix.tolowercase()) == 0) "".equals(prefix)) { 9 matcheslist.add(elem.getstate()); 10 } 11 } 12 } else { 13 for (Capital capital : capitals) { 14 matcheslist.add(capital.getstate()); 15 } 16 } 17 } 4.4 Slider The <rich:inputnumberslider> component is an input component for numerical values that can optionally include control arrows to step through the values, a tooltip to display the value while sliding, and a text field for typing the numerical value which can then be validated against the slider s range. Basic use of the component with no attributes specified will render a slider with a minimum value of 0, a maximum of 100, and a gradient step of 1, together with a text field for typing the desired numerical value. The <rich:inputnumberslider> component is highly customizable, e.g. input can be hidden, boundary values do not have to be displayed, step, minimal and maximal value can be customized, and slider can be displayed horizontally or vertically. PrimeFaces contains a slider component but it is much simpler though. The <p:slider> itself does not contain input but it has to be associated with some text input using attribute 34

42 4. INPUT COMPONENTS Figure 4.6: Default RichFaces slider with value set to 81 for. 1 <h:inputtext id="number" value="#{bean.value}"/> 2 <p:slider for="number" style="width: 150px;"/> Figure 4.7: PrimeFaces slider with default values Similarly to <p:autocomplete> component, no Ajax behavior can be attached to component <p:slider>. Instead, the slideendlistener attribute has to be used which is not standard JSF approach. There is no slider component in OpenFaces nor ICEfaces standard component suite. However, there is a slider component in ICEfaces Enterprise Edition. 4.5 Spinner Spinner is a single-line input field with buttons to increase and decrease a numerical value. In RichFaces, this component is called <rich:inputnumberspinner>. It has practically the same API as <rich:inputnumberslider>. As in RichFaces slider, for basic use only attribute value has to be set (either to an EL expression or a literal). Figure 4.8: RichFaces spinner component Spinner is a very simple component. However, there are som features that can be customized. When changing the value using the buttons, raising the value above the maximum will cause the spinner to restart at the minimum value. Likewise, when lowering below the minimum value the spinner will reset to the maximum value. This behavior can be deactivated by setting cycled to false, which will cause the buttons to stop responding when 35

43 4. INPUT COMPONENTS the reach the maximum or minimum value. The second customizable feature is set with attribute enablemanualinput. When it is set to false, it is not possible to type into spinner s input field. In PrimeFaces, there is <p:spinner> component. Unlike PrimeFaces slider, this components behaves like a JSF component. Similarly to RichFaces slider, it is really easy to start using the component: 1 <p:spinner value="#{bean.value}"/> Many aspects of the component are customizable. Spinner s step can be set using attribute stepfactor, it is possible to set boundaries (i.e. min a max value), and using the attributes prefix and suffix it is possible e.g. to display spinners containing currency symbol. 1 <p:spinner value="#{bean.value}" prefix="$"> 2 <f:convertnumber currencysymbol="$" type="currency"/> 3 </p:spinner> OpenFaces contain a spinner component, too. It has features very similar to PrimeFaces and RichFaces spinner and practically identical API. It is possible to disabled manual input by setting attribute typingallowed to false. Buttons can be placed either on the left or on the right of spinner s input. This can be achieved by using attribute buttonalignment. 1 <o:spinner id="input" value="#{bean.value}" prompttext="click here to edit" 2 minvalue="0" maxvalue="10" step="0.1"> 3 <o:ajax render="output"/> 4 </o:spinner> However the example above is very simple, it does not work because of an exception returned in response for Ajax request: 1 <partial-response> 2 <error> 3 <error-name>class java.lang.illegalstateexception</error-name> 4 <error-message> 5 <![CDATA[org.openfaces.component.ajax.AjaxHelper]]> 6 </error-message> 7 </error> 8 <extension ln="openfaces" ajaxresult="null" type="ajaxresult"> 9 </extension> 10 </partial-response> This bug is caused by JSF itself. It was reported as JSF issue It is marked as critical and should be resolved in Mojarra 2.2. There is a workaround for this issue, though. The following context parameter has to be set in web.xml pointing to the problematic page(s). 1. JSF Jira, 36

44 1 <context-param> 2 <param-name>javax.faces.full_state_saving_view_ids</param-name> 3 <param-value>/page.xhtml</param-value> 4 </context-param> 4. INPUT COMPONENTS Then, <o:ajax> has to be replaced with <f:ajax>. After that, Ajax requests should be fired and output should be updated as expected. There is no spinner component is standard ICEfaces component suite. However, there are number spinner, date spinner, and text spinner components in ICEfaces Enterprise Edition. 4.6 File Upload Many web applications require or allow their users to upload files. In RichFaces, there is component <rich:fileupload> that features multiple uploads, progress bars, restrictions on file types, and restrictions on sizes of the files to be uploaded. Basic usage requires the fileuploadlistener attribute. Use the attribute to reference a listener function on the server side after each file is uploaded. The listener should process files as required, such as storing them in the session, database, or filesystem directory. The component itself does not store uploaded files, so if the listener is not implemented they are not stored anywhere. [15, section rich:fileupload] 1 <rich:fileupload fileuploadlistener="#{bean.listener}" /> Depending on org.richfaces.fileupload.createtempfiles context parameter of the web.xml, files will be uploaded to either a temporary directory (depending on operating system) or to RAM. If the value is true, they will be uploaded to a temporary directory. To limit the maximum size of the uploaded files, it is necessary to define the context parameter org.richfaces.fileupload.maxrequestsize in the web.xml. Its value is defined in bytes. Figure 4.9: RichFaces file upload with selected files and during the uploading 37

45 4. INPUT COMPONENTS PrimeFaces file upload is based on Flash. If the user agent does not support JavaScript or Flash, it fallback to the standard input with type set to file. First of all, PrimeFaces file upload requires two additional dependencies, namely commonsfileupload version and commons-io version 1.4 or newer. Then, file upload filter has to be defined in application s web.xml. Moreover, this filter has to be listed first. 1 <filter> 2 <filter-name>primefaces FileUpload Filter</filter-name> 3 <filter-class>org.primefaces.webapp.filter.fileuploadfilter</filter-class> 4 </filter> 5 <filter-mapping> 6 <filter-name>primefaces FileUpload Filter</filter-name> 7 <servlet-name>faces Servlet</servlet-name> 8 </filter-mapping> Figure 4.10: PrimeFaces file upload with selected files and during uploading It is possible to configure <p:fileupload> for single or multiple uploads. Upload can be started by clicking on Upload link, however, it is possible to turn on autouploading by setting attribute auto to true. Like in RichFaces, uploads can be restricted to only specified file types. To use this feature, attribute allowtypes has to contain a list of file extensions to accept separated with semicolons. Size limit for uploaded files can be specified (in bytes) in attribute sizelimit, not in context parameter like in RichFaces. ICEfaces contain component <ace:fileentry> which has very similar features to Prime- Faces and RichFaces file upload components. It uses a special AJAX technique for allowing ICEfaces incremental page updates within HTML 4 compliant browsers. Files and other form elements are all uploaded and processed together in a single JSF lifecycle. Attribute absolutepath, or alternatively relativepath, determine the root directory into which files will be stored. If absolutepath is specified, then it is interpreted as an absolute path into the file-system. As well, it takes precedence if relativepath is also specified, erroneously. If relativepath is specified, it is interpreted as a path within the application deployment directory. Component s attributes maxtotalsize, maxfilesize and maxfilecount allow for setting quota constraints on upload operations. They are evaluated and enforced for each individual form submit and upload. In ICEfaces only 38

46 <h:commandbutton> can be used to upload files. [14, section FileEntry] 4. INPUT COMPONENTS Figure 4.11: Two ICEfaces file entry components before and after uploading files There is no component for uploading files in OpenFaces. 39

47 5 Output Components 5.1 Progress Bar The <rich:progressbar> component displays a progress bar to indicate the status of a process to the user. It can update either through Ajax or on the client side, and the look and feel can be fully customized. Basic usage of the component <rich:progressbar> requires the value attribute, which points to the property that holds the current progress value. When the value is greater than or equal to the minimum value (0 by default), the progress bar becomes active, and starts sending Ajax requests if in ajax mode. [15, section rich:progressbar] The basic usage is very simple, only attribute value has to be specified: 1 <rich:progressbar value="#{bean.currentvalue}" /> Progress bar s label can be customized in two ways either by using attribute label or by using nested child elements: 1 <rich:progressbar value="#{bean.currentvalue}"> 2 <h:outputtext value="#{bean.currentvalue} % complete"/> 3 </rich:progressbar> Figure 5.1: RichFaces progress bar with a label RichFaces progress bar allows users to define two facets, initial and finish. 1 <rich:progressbar value="#{bean.currentvalue}"> 2 <f:facet name="initial"> 3 <h:outputtext value="process has not started yet"/> 4 </f:facet> 5 <f:facet name="finish"> 6 <h:outputtext value="process has completed"/> 7 </f:facet> 8 </rich:progressbar> The <rich:progressbar> supports two modes ajax and client. The progress bar in ajax mode works in the same way as the <a4j:poll> component. The component repeatedly polls the server for the current progress value. When in client mode, the progress bar must be explicitly updated on the client side through the JavaScript API. PrimeFaces progress bar is much simpler than RichFaces one but on the other hand it can be styled better. It also can work in client and ajax mode. To use it in client mode, JavaScript functions handling starting and stopping the progress bar have to be defined. 1 <p:progressbar widgetvar="pb" style="width: 200px"/> 2 <p:commandbutton value="start" type="button" onclick="start()"/> 40

48 3 <p:commandbutton value="stop" type="buton" onclick="stop()"/> 4 5 <script type="text/javascript"> 6 function start() { 7 this.progressinterval = setinterval(function() { 8 pb.setvalue(pb.getvalue() + 2); 9 }, 2000); 10 } function stop() { 13 clearinterval(this.progressinterval); 14 pb.setvalue(0); 15 } 16 </script> 5. OUTPUT COMPONENTS Figure 5.2: PrimeFaces progress bar There is a progress bar component in ICEfaces, too. The component supports both determinate and indeterminate modes. The component is used in very similar way like progress bars in other component libraries. Figure 5.3: ICEfaces output progress There is no progress bar component in OpenFaces. 5.2 Tree Tree is a component used for displaying hierarchical data. The <rich:tree> component provides a hierarchical tree control. Each <rich:tree> component typically consists of several <rich:treenode> child components. The appearance and behavior of the tree and its nodes can be fully customized. The <rich:tree> component requires only value attribute pointing to the data model. According to RichFaces Component Reference [15, section rich:tree], the data model must be either an org.richfaces.model.treenode interface, an org.richfaces.model.treedatamodel interface, or a javax.swing.tree.treenode interface. The var at- 41

49 5. OUTPUT COMPONENTS tribute declares the variable used for iterating through the data model, so that child <rich: treenode> components can reference each iteration. Ideally, the <rich:tree> component needs one or more <rich:treenode> components to work with the data model. However if no <rich:treenode> components are provided the tree creates default nodes instead. Figure 5.4: Simple RichFaces tree, picture from RichFaces Component Reference [15] Different nodes can have different appearance including font and icons for collapsed and expanded state (see Figure 5.4). Expanding and collapsing nodes can work in three modes: client, ajax, and server. Similarly, these three modes can be used also for selecting tree nodes. In RichFaces, there are tree adaptors which can be used for populating tree model with non-hierarchical data, such as list or map. The <rich:treemodeladaptor> component is added as a nested child component to a <rich:tree> component, or to another tree adaptor component. The <rich:treemodeladaptor> component requires the nodes attribute for basic usage. The nodes attribute defines a collection of elements to iterate through for populating the nodes. The <rich:treemodeladaptor> is not the only adaptor. The component <rich:treemodelrecursiveadaptor> iterates through recursive collections in order to populate a tree with hierarchical nodes, such as for a file system with multiple levels of directories and files. An example can be found in RichFaces Component Reference. [15, section rich:treemodelrecursiveadaptor] PrimeFaces tree is populated with a org.primefaces.model.treenode instance which corresponds to the root. 1 public TreeNode getmodel() { 2 TreeNode root = new DefaultTreeNode("Root", null); 3 TreeNode node0 = new DefaultTreeNode("Node 0", root); TreeNode node00 = new DefaultTreeNode("Node 0.0", node0); return root; 8 } 42

50 5. OUTPUT COMPONENTS 1 <p:tree value="#{treebean.root}" var="node"> 2 <p:treenode> 3 <h:outputtext value="#{node}"/> 4 </p:treenode> 5 </p:tree> Figure 5.5: PrimeFaces tree Like <rich:tree>, PrimeFaces tree also support client (called non-dynamic) and Ajax (called dynamic) mode for toggling. PrimeFaces tree supports three modes for nodes selection: single; multiple; and checkbox. When the checkbox mode is selected, a checkbox is rendered next to each node. ICEfaces also contains a highly customizable tree component. ICEfaces tree may display navigation controls for the dynamic expansion and collapse of branch nodes and nodes may support an action event when clicked that can be used to respond to user click events. In order to use ICEfaces tree, it is necessary to define tree model first. Tree model in ICEfaces is represented by class javax.swing.tree.defaulttreemodel. The following code demonstrates creation of a tree model for the <ice:tree> component: 43

51 5. OUTPUT COMPONENTS Figure 5.6: PrimeFaces tree with selection mode set to checkbox 1 // create root node with its children expanded 2 DefaultMutableTreeNode roottreenode = new DefaultMutableTreeNode(); 3 IceUserObject rootobject = new IceUserObject(rootTreeNode); 4 rootobject.settext("root Node"); 5 rootobject.setexpanded(true); 6 roottreenode.setuserobject(rootobject); 7 8 // model is accessed by by the ice:tree component via a getter method 9 DefaultTreeModel model = new DefaultTreeModel(rootTreeNode); // add some child nodes 12 for (int i = 0; i < 3; i++) { 13 DefaultMutableTreeNode branchnode = new DefaultMutableTreeNode(); 14 IceUserObject branchobject = new IceUserObject(branchNode); 15 branchobject.settext("node " + i); 16 branchnode.setuserobject(branchobject); 17 for (int j = 0; j < 5; j++) { 18 DefaultMutableTreeNode subbranchnode = new DefaultMutableTreeNode(); 19 IceUserObject subbranchobject = new IceUserObject(subbranchNode); 20 subbranchobject.settext("node " + i + "." + j); 21 subbranchnode.setuserobject(subbranchobject); 22 branchnode.add(subbranchnode); 23 } 24 roottreenode.add(branchnode); 25 } After the model is created, the component can be used on a page as follows which will render as a tree in Figure <ice:tree id="tree" value="#{icetreebean.model}" var="item" 2 hiderootnode="false" hidenavigation="false" 3 imagedir="./xmlhttp/css/xp/css-images/" > 4 44

52 5 <ice:treenode> 6 <f:facet name="content"> 7 <ice:panelgroup style="display: inline"> 8 <ice:outputtext value="#{item.userobject.text}" /> 9 </ice:panelgroup> 10 </f:facet> 11 </ice:treenode> </ice:tree> 5. OUTPUT COMPONENTS There is no tree component in OpenFaces. Figure 5.7: ICEfaces tree 45

53 6 Panels It is usually necessary to organize elements of pages into smaller parts. JSF and extending libraries contain few container components such as simple panels, tab panel, togglable panels, wizards, etc. 6.1 Panels in RichFaces The <rich:panel> is a bordered panel with an optional header. If no attributes are defined, a simple bordered panel without any header will be rendered. There are two way for defining header of panel using attribute header or using facet header. 1 <rich:panel header="header of panel"> 2 Lorem ipsum... 3 </rich:panel> 4 5 <rich:panel> 6 <f:facet name="header"> 7 <h:outputtext value="header of panel"> 8 </f:facet> 9 Lorem ipsum </rich:panel> Figure 6.1: RichFaces panel with header In addition to simple panel, RichFaces contain also several advanced panels, namely collapsible panel, toggle panel, tab panel, and accordion. All listed RichFaces panels have attribute switchtype which influence the way how the panels are toggled. There are three options: server performs standard HTTP request; ajax performs Ajax request; and 46

54 6. PANELS client toggles panel on the client without firing any request. The <rich:accordion> is a series of panels stacked on top of each other, each collapsed such that only the header of the panel is showing. All togglable panels are easy to use and all share the same API. The <rich:accordion> component is used together with <rich :accordionitem>, <rich:tabpanel> with <rich:tab>, and <rich:togglepanel> with <rich:togglepanelitem> component. 1 <rich:accordion id="accordion" switchtype="ajax"> 2 <rich:accordionitem id="item1" name="item1" header="item 1"> 3 content of item 1 4 </rich:accordionitem> 5 <rich:accordionitem id="item2" name="item2" header="item 2"> 6 content of item 2 7 </rich:accordionitem> </rich:accordion> Figure 6.2: RichFaces accordion with five accordion items and fourth item disabled The <rich:collapsiblepanel> looks like simple <rich:panel> but it can be toggled. All RichFaces panels are highly customizable, e.g. it is possible to set icons on the left and on the right in all states. The <rich:popuppanel> component provides a window that appears in front of the rest of the application. The <rich:popuppanel> component functions either as a modal window which blocks interaction with the rest of the application while active, or as a non-modal window. This functionality can be turned on or off by setting attribute modal to true or false. It can be movable and resizable. The popup panel is usually opened and closed on the client using JavaScript API. In order not to use JavaScript directly, one can use the <rich: componentcontrol> component. The pop-up panel can be automatically sized when it is shown if the autosized attribute is set to true. 1 <h:commandbutton id="openpanelbutton" value="call the popup" 47

55 6. PANELS Figure 6.3: RichFaces collapsible panel in expanded and collapsed state 2 moveable="true"> 3 <rich:componentcontrol target="popuppanel" operation="show" /> 4 </h:commandbutton> 5 <rich:popuppanel header="header of the panel"> 6 content... 7 </rich:popuppanel> Figure 6.4: RichFaces popup panel 6.2 Panels in PrimeFaces PrimeFaces contain component called <p:panel> which is very similar to RichFaces panel. It also enables user to define header as attribute or as facet. Moreover, PrimeFaces panel 48

56 6. PANELS component allows the user to define also footer in the same way as header. PrimeFaces panel can be made togglable using attribute toggleable set to true. When it is desired to get notified on server side when a panel is toggled, it is possible to do so by using Ajax togglelistener. Unlike RichFaces panel, PrimeFaces panel can be made closable. In order to make panel closable, its attribute closeable has to be set to true. Last but not least important feature of the <p:panel> is the ability to define popup menus in its header. To use this feature, facet options has to contain <p:menu> component. Figure 6.5: Togglable and closable PrimeFaces panel There is <p:accordionpanel> component in PrimeFaces. It is used in connection with several <p:tab> components. It is possible to define an effect that will be used for switching tabs. 1 <p:accordionpanel id="accordionpanel" effect="hover"> 2 <p:tab id="item1" title="item 1"> 3 content of item 1 4 </p:tab> 5 <p:tab id="item2" title="item 2"> 6 content of item 2 7 </p:tab> </p:accordionpanel> 49

57 6. PANELS Figure 6.6: PrimeFaces accordion panel with second tab expanded There is also a tabbed panel in PrimeFaces called tab view. It is possible to take accordion panel sample and change top-level tag and the tab panel will be rendered: 1 <p:tabview id="tabpanel" effect="hover"> 2 <p:tab id="item1" title="item 1"> 3 content of item 1 4 </p:tab> 5 <p:tab id="item2" title="item 2"> 6 content of item 2 7 </p:tab> </p:tabview> Figure 6.7: Simple PrimeFaces tab view There is a component similar to RichFaces popup panel called dialog. It has almost the same feature set. The component is controlled by JavaScript. Since PrimeFaces do not have anything like <rich:componentcontrol>, it is needed to define attribute widgetvar. This defines the name of the widget which can be then used in JavaScript. This is commonly used concept in PrimeFaces. 1 <a href="#" onclick="dialog.show()">show</a> 2 <a href="#" onclick="dialog.hide()">hide</a> 3 4 <p:dialog header="panel Header" widgetvar="dialog" closable="true"> 50

58 6. PANELS 5 content... 6 </p:dialog> 6.3 Panels in OpenFaces OpenFaces contains several panel components, too. The one similar to RichFaces collapsible panel is called folding panel. It is used in a very similar way: 1 <o:foldingpanel caption="header of panel"> 2 content... 3 </o:foldingpanel> OpenFaces folding panel can work in three modes similar to those in RichFaces (client, server, and ajaxalways). Moreover, there is one extra mode called ajaxlazy. In this mode, the content of the panel is loaded from the server with Ajax request. Once loaded, it is cached on the client and shown without additional server requests on further expansions. Figure 6.8: OpenFaces folding panel in expanded state By default, the folding panel component expands downwards. However, it is possible to configure it to expand in other directions using attribute foldingdirection (possible options are up, down, left, and right). The layered pane component is similar to the <rich:togglepanel>. It is used together with <o:subpanel> child components. Like in folding panel, this component also can work in four modes including ajaxlazy. 1 <o:layeredpane id="layeredpane" loadingmode="client"> 2 <o:subpanel> 3 content 1 4 </o:subpanel> 5 <o:subpanel> 6 content 2 7 </o:subpanel> </o:layeredpane> 51

59 6. PANELS OpenFaces do not contain full-fledged popup panel. Although there is a universal component <o:popuplayer>, it is rather a general container for other components. It supports dragging, resizing and even modal mode. However, it does not define any header. The <o:tabbedpane> component can be used instead of <rich:tabpanel>. It is used together with <o:subpanel> component. It is possible to use tag <o:subpanels> in order to generate tabs dynamically in both <o:tabbedpane> and <o:layeredpane>. It is possible to customize the placement of the tabs. To do so, the attribute tabplacement has to be set to one of top, left, bottom, or right. One unique feature of the <o:tabbedpane> is out of the box keyboard support. It is possible to use up, down, left, and right keys to navigate in a tabbed pane. 1 <o:tabbedpane> 2 <o:subpanel caption="first tab"> 3 <h:outputtext value="some text on the first tab" /> 4 </o:subpanel> 5 <o:subpanel caption="second tab"> 6 <h:outputtext value="some text on the second tab"/> 7 </o:subpanel> 8 </o:tabbedpane> Figure 6.9: OpenFaces tab panel with fourth tab active 6.4 Panels in ICEfaces ICEfaces contain a collapsible panel component which is used in the same way as <rich :collapsiblepanel>. Although it is very similar to RichFaces collapsible panel, it supports only Ajax mode. 1 <ice:panelcollapsible id="panel" style="width: 600px;"> 2 3 <f:facet name="header"> 4 <ice:panelgroup> 5 <ice:outputtext value="lorem Ipsum"/> 6 </ice:panelgroup> 7 </f:facet> Lorem ipsum </ice:panelcollapsible> 52

60 6. PANELS Figure 6.10: ICEfaces collapsible panel ICEfaces contain a basic togglable panel called panel stack. It is similar to RichFaces toggle panel which does not render any additional markup. The component <ice:panelstack> has to contain one or more <ice:panelgroup> child components. The panel stack component can be used in cases where a form region must contain several embedded panels, only one of which is visible at one time, changing dynamically depending on an application state change or user selection. 1 <ice:selectoneradio value="#{bean.selectedpanel}"> 2 <f:selectitem itemvalue="panel1"/> 3 <f:selectitem itemvalue="panel2"/> 4 <f:selectitem itemvalue="panel3"/> 5 </ice:selectoneradio> 6 7 <ice:panelstack id="stack" selectedpanel="#{bean.selectedpanel}"> 8 <ice:panelgroup id="panel1">... </ice:panelgroup> 9 <ice:panelgroup id="panel2">... </ice:panelgroup> 10 <ice:panelgroup id="panel3">... </ice:panelgroup> 11 </ice:panelstack> The <ice:paneltabset> is a container component which represent a tab panel. It itself contains one or more <ice:paneltab> components which are also container components. It is used in a similar way as <rich:tabpanel>. 1 <ice:paneltabset id="stack" selectedindex="#{bean.selectedpanel}"> 2 <ice:paneltab id="tab1" label="tab 1">...</ice:panelTab> 3 <ice:paneltab id="tab2" label="tab 2">...</ice:panelTab> 4 <ice:paneltab id="tab3" label="tab 3">...</ice:panelTab> 5 <ice:paneltab id="tab4" label="tab 4">...</ice:panelTab> 6 </ice:paneltabset> There is a popup panel in ICEfaces which can be, like popup panels in other libraries, movable, modal or non-modal. Unlike RichFaces popup panel, ICEfaces panel cannot be resizable. Although it has attribute resizable, it has not been implemented in version The other difference from RichFaces panels is that it does not support client mode. 1 <ice:panelpopup id="popup" visible="#{icepanelpopupbean.visible}" 2 draggable="true" modal="true" autocentre="true"> 3 4 <f:facet name="header"> 5 <ice:panelgroup styleclass="popupheaderwrapper"> 53

61 6. PANELS Figure 6.11: ICEfaces panel tab set with third tab activated 6 <ice:outputtext value="header"/> 7 <ice:commandbutton id="modalpnlclosebtn" type="button" 8 image="/resources/images/popupclose.gif" 9 actionlistener="#{icepanelpopupbean.togglepanel}" 10 styleclass="popupheaderimage" 11 title="close Popup" alt="close"/> 12 </ice:panelgroup> 13 </f:facet> <f:facet name="body">... </f:facet> </ice:panelpopup> Figure 6.12: ICEfaces popup panel in modal mode 54

62 6. PANELS ICEfaces contain a panel that is not in RichFaces a split pane panel. It is a component that is split into two parts horizontally or vertically and serves as a container for other components. User can use panel divider to resize panes. Basic usage is very simple. The following example will be rendered as the panel in Figure <ice:paneldivider> 2 <f:facet name="first"> 3 content of the first pane 4 </f:facet> 5 <f:facet name="second"> 6 content of the second pane 7 </f:facet> 8 </ice:paneldivider> Figure 6.13: ICEfaces panel divider 55

63 7 Iteration Components Creators of web applications need very often to display sets of data in form of a list, table or with some custom markup. JSF 2 contains three components usable for iterating through a list of objects: <h:datatable> renders an HTML <table> element compliant with the HTML specification; one row in table corresponds to one object in list of objects; <h:panelgrid> renders an HTML <table> element, conforming to the rules in the HTML 401 specification; attribute columns specifies how many columns should be rendered before starting a new row; and <ui:repeat> intended as a replacement for the c:foreach tag from the JSTL Core tag library. The following code will render a table with two columns, the first will contain employee s name and the second one will contain employee s phone number: 1 <h:datatable value="#{bean.employees}" var="employee"> 2 <h:column> 3 <f:facet name="header">name</f:facet> 4 #{employee.name} 5 <f:facet name="footer">name</f:facet> 6 </h:column> 7 <h:column> 8 <f:facet name="header">phone Number</f:facet> 9 #{employee.phonenumber} 10 <f:facet name="footer">phone Number</f:facet> 11 </h:column> 12 </h:datatable> Since the standard JSF components are very simple, component libraries came with their own iteration components which usually contain at least one table with advanced features such as column sorting and filtering, scrolling, row selecting, changing column order using drag and drop, and pagination of long data sets. Last but not least they advanced iteration components usually support lazy loading of data. 1 Basically, all iteration components have the same standard API so it is very easy to change implementation, e.g. in the example above, it is possible to change <h:datatable> and <h:column> to <rich:datatable> and <rich:column> respectively and the sample will function without any other modifications. 1. Lazy loading is a design pattern to defer initialization of an object until the point at which it is needed. 56

64 7. ITERATION COMPONENTS 7.1 RichFaces Repeat, List and Data Grid The non-visual <a4j:repeat> component extends the standard UIRepeat component to allow partial updates within iterations while sending Ajax requests. The component acts as a base for all the other RichFaces data iteration components. The component itself does not render any special markup so it is possible to wrap one s data in whichever markup. For instance, it is easy to create a standard HTML unordered list with <a4j:repeat>: 1 <ul> 2 <a4j:repeat value="#{bean.employees}" var="employee"> 3 <li>#{employee.name}: #{employee.phonenumber}</li> 4 </a4j:repeat> 5 </ul> All RichFaces iteration components allow the use of standard attributes first (which object from the collection will be the first displayed) and rows (how many objects ought be rendered) with which it is possible to limit the size of the source data. Moreover, it is possible to attach a <rich:datascroller> to every RichFaces iteration component and thus add pagination to it. This will be explained in detail later in this section. Although it is easy to create an unordered list with <a4j:repeat>, it can be even more simplified by using <rich:list>. RichFaces list component renders unordered, ordered or definition list depending on its type attribute. 1 <rich:list value="#{bean.employees}" var="employee" type="onordered"> 2 #{employee.name}: #{employee.phonenumber} 3 </rich:list> The <rich:datagrid> component is used to arrange data objects in a grid. Values in the grid can be updated dynamically from the data model, and Ajax updates can be limited to specific rows. The component supports header, footer, and caption facets. The component <rich:datagrid> is similar in function to the standard JavaServer Faces component <h:panelgrid>. However, the <rich:datagrid> component additionally allows iteration through the data model rather than just aligning child components in a grid layout. [15, section rich:datagrid] 57

65 7. ITERATION COMPONENTS Figure 7.1: RichFaces data grid with scroller in its footer and columns attribute set to RichFaces Data Table The <rich:datatable> component is used to render a table, including the table s caption. It works in conjunction with the <rich:column> and <rich:columngroup> components to list the contents of a data model. The basic usage is the same as for <h:datatable> but RichFaces data table supports some advanced features, namely filtering and sorting of data. The table supports four self-explaining facets: caption; header; footer; and nodata. It is possible to specify header and footer not only for table but also for each column. The <rich:collapsiblesubtable> component acts as a child element to a <rich: datatable> component. The <rich:collapsiblesubtable> iterates through the child collections in the currently iterated object to create master-detail tables. Additionally, the detail part of the table can be collapsed or expanded through different modes. The <rich :collapsiblesubtable> component works with the collapsible subtable toggler component, which expands and collapses the sub-tables. [15, section rich:collapsiblesubtable] Sample for using collapsible sub tables can be found in Appendix A. 58

66 7. ITERATION COMPONENTS Figure 7.2: RichFaces data table with all facets set with data (left) and without data (right) Figure 7.3: RichFaces data table containing two subtables, the first one is collapsed Table filtering in RichFaces is done using column s attribute filterexpression. This attribute has to be set to an EL expression evaluating to boolean. The expression checks if each table entry satisfies the filtering condition when the table is rendered. For example, the expression might be a JSTL function such as contains or equals. Another approach is to use filter attribute which points to an object which implements the org.richfaces. model.filter<t> interface. The object provides method accept(t t) which takes each iteration object as a parameter and returns a boolean value, which determines whether the object satisfies the filter. By defining a custom filter, it is possible to implement complex business logic to filter a table. [15, section Table filtering] A table s column can be sortable by using the attribute sortby. By default, the target will be sorted using the compare() method. If using custom-defined rules for sorting, the comparator attribute ought be used instead. The sorting order is managed by binding the sortorder attribute to bean properties. If a column is sortable, its header is rendered as a clickable link (see Figure 7.4). Example in Appendix B demonstrates table sorting. 59

67 7. ITERATION COMPONENTS Figure 7.4: RichFaces data table with all columns sortable Last but not least, RichFaces data table adds few self-explaining JavaScript event handlers: onrowclick, onrowdblclick, onrowkeydown, onrowkeypress, onrowkeyup, etc. 7.3 RichFaces Extended Data Table The <rich:extendeddatatable> component extends the functionality of the <rich: datatable> component adding features such as scrolling for the table body (both horizontal and vertical), Ajax loading for vertical scrolling, frozen columns, row selection, and rearranging of columns. It also supports all the basic table features such as sorting, filtering, and paging. In order to freeze some columns so that they will not be scrolled horizontally, attribute frozencolumns has to be set. The result of the following example can be seen on picture Figure <rich:extendeddatatable value="#{carsbean.allinventoryitems}" 2 var="car" id="table" frozencolumns="2" 3 style="height:300px; width:500px;"> </rich:extendeddatatable> Another advanced feature of the extended data table is selection of table rows. There are four modes available: none no row can be selected; single only one row can be selected; 60

68 7. ITERATION COMPONENTS Figure 7.5: RichFaces extended data table with attribute frozencolumns set to 2 multiple multiple rows can be selected, it is possible to use Ctrl and Shift keys for selection; and multiplekeyboardfree similar to the previous mode but multiple rows can be selected without using keyboard. To use this feature of extended data table, it is necessary to set attribute selectionmode to one of the mentioned modes and bind attribute selection with a bean property. 1 <rich:extendeddatatable value="#{exttableselectionbean.inventoryitems}" 2 var="car" selection="#{exttableselectionbean.selection}" 3 id="table" frozencolumns="2" style="height:300px; width:500px;" 4 selectionmode="multiple"> </rich:extendeddatatable> Columns in a <rich:extendeddatatable> component can be rearranged by the user by dragging each column to a different position. A graphical representation of the column is displayed during dragging. Filtering and sorting features are implemented in <rich: extendeddatatable> in the same way as in <rich:datatable>. Pagination is implemented using a data scroller described in the following section. 7.4 RichFaces Data Scroller The <rich:datascroller> component is used for navigating through multiple pages of tables. There are two ways how to use <rich:datascroller>: 1. placing it in a facet of the data table or grid which it needs to control; or 61

69 2. using the for attribute to bind the parent table or grid to the scroller. 7. ITERATION COMPONENTS The bound table or grid should also have the rows attribute defined to limit the number of rows per page. The <rich:datascroller> component must be rerendered whenever a filter changes on the bound table, so that the scroller matches the current model for the table. The table with data scrollers in following example will be rendered like one in Figure <rich:datascroller for="table" maxpages="5"> 2 <rich:datatable id="table" value="#{capitalsbean.capitals}" var="cap" 3 rows="5"> <f:facet name="footer"> 7 <rich:datascroller maxpages="5"> 8 </f:facet> 9 </rich:datatable> The appearance of the component can be customized using facets (first, last, next, previous, fastforward, and fastrewind). Additionally, there are facets for the controls disabled states: first_disabled, last_disabled, next_disabled, etc. The attribute maxpages can be used to limit the number of page controls that appear. Figure 7.6: RichFaces data table with two scrollers The <rich:datascroller> component is not limited only to RichFaces data table but it can be used with all standard JSF iteration components and with all RichFaces iteration components. Moreover, it is possible to use <rich:datascroller> for scrolling PrimeFaces iteration components. 62

70 7. ITERATION COMPONENTS 7.5 OpenFaces ForEach The ForEach component is an iteration component that renders the specified set of components multiple times based on its parameters. The ForEach component is similar to the JSTL <c:foreach> tag and RichFaces <a4j:repeat>. It is used in similar way as <a4j: repeat>: 1 <ul> 2 <o:foreach items="#{bean.employees}" var="employee"> 3 <li>#{employee.name}: #{employee.phonenumber}</li> 4 </o:foreach> 5 </ul> Although <o:foreach> component is very similar to <a4j:repeat> component, there are two differences for which it is more generally usable. First, it contains attribute step which specifies the index increase step between the successive iteration rounds. Using this, it is possible to render only every third row or iterate backwards. the second feature is extended support for types usable in attribute items. Unlike in standard JSF components and RichFaces components, it is possible to use any of these: java.util.collection (or any of its implementations); array; javax.faces.model.datamodel (or any of its implementations); java.sql.resultset; or javax.servlet.jsp.jstl.sql.result. 7.6 OpenFaces Data Table The <o:datatable> component provides all the advanced functionality that RichFaces extended data table provides. The <o:datatable> component defines several facets above, below, header, subheader, footer, and nodatamessage. The content of facet above renders before the table and facet below renders after the table. Inside OpenFaces data table, it is possible to use <o:column> which renders standard column with content by user. Another option is to use <o:selectioncolumn> which renders a column with checkboxes for multiple row selection or radio buttons for single row selection. The third tag usable inside <o:datatable> is <o:checkboxcolumn> which renders a column of checkboxes whose values are not store in the row data object. OpenFaces data table provides an ability to specify dynamic number of columns it is done using <o: columns>. 63

71 7. ITERATION COMPONENTS It is possible to let the user reorder columns interactively with drag and drop by adding the <o:columnreordering> tag into the <o:datatable> tag. When this feature is turned on, the user can drag the column by its header and drop it into the appropriate place inbetween columns. The current drop target is highlighted for user s convenience. [16, section Data Table] Figure 7.7: OpenFaces data table with scrolling, filtering and sorting turned on Columns can be made resizable by adding the <o:columnresizing> tag as a child of <o: datatable> tag. When column resizing is turned on, the user can drag the column header separators to resize columns. The total table width is not affected by the process of resizing columns. Sample data table with resizable columns might look like this: 1 <o:datatable var="employee" value="#{bean.employees}" width="100%"> 2 <o:columnresizing resizehandlewidth="10px" mincolwidth="100px"/> 3 <o:column id = "name"> #{employee.name}</o:column> 4 <o:column id = "title"> #{employee.title}</o:column> 5 </o:datatable> One of the features that differ <o:datatable> from RichFaces tables is ability to add the column menu to allow performing the standard column operations such as sorting, showing and hiding columns, or to provide custom column-specific operations. This feature is turned on by specifying the columnmenu facet. Specifying this facet makes a drop-down button to appear in the column s header when the user hovers over the header and pressing this button shows the menu. It is possible to specify the standard column menu with the tag <o:columnmenu> in this facet, or a custom menu with the <o:popupmenu> facet. The following sample from OpenFaces Developers Guide [16, section Data Table] illustrates how to use this feature: 1 <o:datatable id="table"...>

72 7. ITERATION COMPONENTS 3 <f:facet name="columnmenu"> 4 <o:columnmenu indentstyle="color: yellow"> 5 <o:sortascendingmenuitem/> 6 <o:sortdescendingmenuitem/> 7 <o:hidecolumnmenuitem/> 8 <o:menuseparator/> 9 <o:menuitem value="columns"> 10 <o:columnvisibilitymenu/> 11 </o:menuitem> 12 <o:menuseparator/> 13 <o:menuitem value="select Column" onclick="selectcolumn(o$( form:table ).getcurrentcolumn().index);"/> 14 <o:menuitem value="unselect Column" onclick="unselectcolumn(o$( form: table ).getcurrentcolumn().index);"/> 15 </o:columnmenu> 16 </f:facet> </o:datatable> Sometimes the data set is too big and therefore also the table is too long and takes too much space on the page. In such case, it is possible to configure <o:datatable> to scroll its content. This can be done simply by placing the <o:scrolling> inside of the <o: datatable> component. Header and footer rows remain fixed independent of scrolling. Sample data table with vertical scrolling is displayed in the picture in Figure 7.7. Similarly to RichFaces extended data table s attribute frozencolumns, it is possible to exclude one or more columns from horizontal scrolling and fix them on the table s left or right side by specifying the fixed attribute of the appropriate column: 1 <o:datatable...> 2 <o:scrolling horizontal="true"/> 3 <o:column fixed="true".../> 4 <o:column.../> 5 <o:column.../> </o:datatable> To enable pagination in the <o:datatable> component, one need to specify the pagesize attribute. This attribute defines the number of rows to be displayed on each data table page. If it is set to 0 (default), no pagination is provided. Also, optionally one can use the pageindex attribute to specify the number of a currently displayed table page. Similarly to RichFaces, setting an attribute is not sufficient. The <o:datatablepaginator> component has to be placed on the page. The paginator component has to be placed inside the below or above facets of an <o:datatable> and its id attribute has to be specified. Open- Faces paginator can be customized in many ways similarly to the <rich:datascroller> component. Sorting in OpenFaces data table can be turned on using attributes sortingexpression and sortingcomparator of a column. Sorting expression defines row s value that will 65

73 7. ITERATION COMPONENTS Figure 7.8: OpenFaces data table with paginator placed inside table s below facet be used for sorting. It should contain an EL expression. The sortingcomparator attribute defines the comparator that is used to compare the values provided by the attribute sortingexpression. This attribute should be specified as a value-binding expression and should reference the object that implements the java.util.comparator interface. If the sortingcomparator attribute is not defined, sortingexpression should evaluate to either a primitive type or an object that implements the java.lang.comparable interface, for example String. [16, section Data Table] In Figure 7.7 the column Institution Name is sortable and is set to sort ascending. 1 <o:datatable var="employee" value="#{bean.employees}"> 2 <o:column id="namecolumn" sortingexpression="#{emplyee.name}" 3 sortingcomparator="caseinsensitivetext"> 4 <f:facet name="header"> 5 Name 6 </f:facet> 7 <h:outputtext id="name" value="#{employee.name}" /> 8 </o:column> </o:datatable> Filtering in <o:datatable> component is implemented in a very general way and in many aspects is easier to use than filtering in RichFaces data table or extended data table. Open- Faces Developer Guide [16, section Data Table] lists what is possible with filtering feature in OpenFaces data table: define column data filters; define filters that search data on a complex expression rather than a single-column expression; use different types of filter components; place filter components inside of the table or anywhere on the page; 66

74 7. ITERATION COMPONENTS customize all aspects of filtering behavior including search condition, case sensitivity, etc.; customize all aspects of filters visual appearance; use the composite filter builder 2 as a universal filter component to allow the user build complex filter criteria interactively; and easily add support for handling large data sets while utilizing all kinds of filters attached to the table. Even though the list of features is long, it is quite easy to incorporate filtering into a table. The filtering functionality is defined using one of the filter tags (<o:inputtextfilter >, <o:dropdownfieldfilter>, <o:comboboxfilter>, or <o:compositefilter>). These filters can be used in two ways. First, a filter tag can be placed anywhere in column s facet. Second way is to place a filter anywhere on the page and specify the for attribute which works in the same way as for attribute of <h:outputlabel>. Figure 7.9 shows a data table with filtering define as in the following code snippet. The first column contains a combo box filter which displays a drop-down field with all possible values for given attribute of the bean. The second column contains an input text filter which renders an input text field and so it is possible to input whichever string. There is a special attribute called condition which accepts simple conditions like contains, beginswith, less, greaterorequal, etc. It is even possible to create negative predicates. The third column in Figure 7.9 contains a drop down field filter. It filters the data according to the expression specified in the filter. This filter autocompletes user-typed input by default. Both <o:comboboxfilter> and <o:dropdownfieldfilter> are filled with select options according to actual context (see Figure 7.9). 1 <o:datatable...> <o:column id="columnsex"> 4 <f:facet name="header"> <o:comboboxfilter expression="#{record.sex}"/> 7 </f:facet> </o:column> <o:column id="columnname"> 12 <f:facet name="header"> <o:inputtextfilter casesensitive="false" condition="contains" 15 expression="#{record.name}"/> 16 </f:facet> </o:column> The composite filter component 67

75 20 <o:column id="columntitle"> 21 <f:facet name="header"> <o:dropdownfieldfilter expression="#{record.title}" 24 autocomplete="false" autofilterdelay="500"/> 25 </f:facet> </o:column> </o:datatable> 7. ITERATION COMPONENTS Figure 7.9: OpenFaces data table with filtering using three types of filter The last noteworthy feature of the <o:datatable> component is row selection. There are two row selection modes available: single and multiple. Like in RichFaces, a user can select the rows either using mouse or using keyboard. Optionally, user can add a checkbox column to the table which render checkboxes usable for selection. The following example defines two data tables with different selection mode the first one uses single mode and the second one uses multiple mode. 1 <o:datatable var="employee" value="#{bean.employees}" > 2 <o:singlerowselection rowdata="#{bean.selectedemployee"/> 3 <o:column> 4 <f:facet name="header"> 5 <h:outputtext value="name"/> 6 </f:facet> 7 <h:outputtext value="#{employee.name}" /> 8 </o:column> 9 </o:datatable> <o:datatable var="employee" value="#{bean.employees}" > 12 <o:multiplerowselection rowdatas="#{bean.selectedemployees}"/> 13 <o:column> 14 <f:facet name="header"> 15 <h:outputtext value="name"/> 16 </f:facet> 17 <h:outputtext value="#{employee.name}" /> 68

76 7. ITERATION COMPONENTS 18 </o:column> 19 </o:datatable> Figure 7.10: OpenFaces data table with row selection in multiple mode and checkbox column 7.7 PrimeFaces Data Grid PrimeFaces data grid component is very similar to standard <h:panelgrid> and <rich :datagrid> components. It even has the same API. Simple <p:datagrid> might be defined like in the following example. 1 <p:datagrid id="datagrid" value="#{model.capitals}" var="record" 2 columns="3" rows="9" paginator="true"> 3 <p:panel header="#{record.state}"> 4 <h:outputtext value="#{record.name}" /> 5 </p:panel> 6 </p:datagrid> The <p:datagrid> component provides very comparable functionality to RichFaces data grid. PrimeFaces data grid supports pagination. However, it is implemented in different way than in OpenFaces or RichFaces. The compononent has an attribute paginator which, when set to true, will render two paginators one above the data grid and one below. Using the paginatorposition attribute it is possible to specify where the paginator will be displayed. The attribute accepts three values: top, bottom, and both (default). Moreover, it is possible to customize paginator using so called paginator template set in attribute paginatortemplate. This attribute accepts the following keywords: FirstPageLink; LastPageLink; PreviousPageLink; 69

77 7. ITERATION COMPONENTS NextPageLink; PageLinks; CurrentPageReport; and RowsPerPageDropDown. To customize paginator, these keywords have to be put into curly brackets. The default template corresponds to the following string: 1 {FirstPageLink} {PreviousPageLink} {PageLinks} {NextPageLink} {LastPageLink} One feature that is unique for PrimeFaces data grid is ability to define effects for transitioning between pages of a data grid. When the attribute effect is set to true, the switching pages will not be animated. Moreover, it is possible to define the speed of the effect using effectspeed attribute (possible values are slow, normal, and fast). Figure 7.11: PrimeFaces data grid with paginators 7.8 PrimeFaces Data List Like RichFaces, also PrimeFaces has a component rendering a list. The way of use is pretty similar to RichFaces list. The list can contain paginator and effect for which the same rules apply as for paginator and effect in PrimeFaces data grid. Similarly to RichFaces, the <p :datalist> component supports three types of lists unordered, ordered, and definition list. Although it is possible to use custom bullets in <rich:list> using CSS, in PrimeFaces it is made easier using the attribute itemtype. There are several options for itemtype attribute, such as disc, circle, and square for unordered lists. For ordered lists, there are these options: 70

78 7. ITERATION COMPONENTS 1 renders a sequence of numbers; a renders a sequence of lower-case characters; A renders a sequence of upper-case characters; and i renders a sequence of Roman numerals. Figure 7.12: PrimeFaces ordered data list 7.9 PrimeFaces Data Table PrimeFaces data table, while very similar to OpenFaces and RichFaces data tables, it has one special feature. It can work in two modes: dynamic and non-dynamic. According to PrimeFaces Developer Guide [22, p. 111] when a table is non-dynamic (default) it works as a pure client side component. Dynamic data tables fetch their data from backing bean model with Ajax. Features including paging, sorting and filtering are both implemented on client side and server side. For small data sets non-dynamic data tables are much faster and have the advantage of avoiding roundtrips to server with Ajax. Pagination in the <p:datatable> is implemented in exactly the same way as in Prime- Faces data grid and data list components. To make a column sortable, it is needed to define sortby attribute. If the table is in nondynamic mode, attribute parser has to be defined, too. This defines client-side parsers for column data. Possible values are string, number and date. In the case that user needs to use custom sorting function, the attribute sortfunction has to be defined. This attribute ought be bound to a method with two parameters and it should return integer. 1 public int sort(employee e1, Employee e2) { 2 // performs comparison and returns -1 if e1 < e2, 0 if e1 = e2, 1 if e1 > e2 3 } If the table is in non-dynamic mode, a JavaScript function has to be provided in attribute sortfunction. In the following example a and b are JavaScript objects representing row 71

79 7. ITERATION COMPONENTS data, desc is a boolean value representing sorting order (true for descending) and field represents column key to be used to retrieve column value. 1 sort = function(a, b, desc, field) { 2 var val1 = a.getdata(field); 3 var val2 = b.getdata(field); 4 // return an integer -1, 0, or 1 5 } Like RichFaces and OpenFaces, PrimeFaces table support two modes for selection of rows single and multiple. To turn on the selection, attribute selectionmode has to be set. In addition to the two mentioned modes for selecting rows of table, PrimeFaces table support also selecting cells of a table. It is possible to select one cell or block of cells. Filtering is implemented in PrimeFaces by using attribute filterby bound to managed bean property that ought be used for filtering. By default, filtering is triggered by keyup event but it is configurable using attribute filterevent ICEfaces Data Table ICEfaces contain a data table that is functionally comparable to RichFaces, OpenFaces and PrimeFaces data tables. It can be very minimalist but also its functionality can be greatly extended when combined with the components <ice:commandsortheader> and <ice :datapaginator>. The <ice:commandsortheader> component allows column based sorting by clicking on a column header. The <ice:datapaginator> renders a paginator for the attached data table. The columns of the table can be made resizable by setting the attribute resizable to true. Basic usage is the same as with standard JSF data table or RichFaces data table: 1 <ice:datatable id="datatable" value="#{model.capitals}" var="record"> 2 3 <ice:column id="columnstate"> 4 <f:facet name="header">state</f:facet> 5 <h:outputtext value="#{record.state}" /> 6 </ice:column> 7 8 <ice:column id="columncapital"> 9 <f:facet name="header">capital</f:facet> 10 <h:outputtext value="#{record.name}" /> 11 </ice:column> </ice:datatable> To make the table paginated, an <ice:datapaginator> has to be used. If the attribute paginator is set to false, the page number links will not be rendered. 72

80 7. ITERATION COMPONENTS 1 <ice:datapaginator id="datascroller" for="datatable" paginator="true" 2 faststep="3" paginatormaxpages="4"> 3 <f:facet name="first" ><h:graphicimage... /></f:facet> 4 <f:facet name="last"><h:graphicimage.../></f:facet> 5 <f:facet name="previous"><h:graphicimage.../></f:facet> 6 <f:facet name="next"><h:graphicimage.../></f:facet> 7 <f:facet name="fastforward"><h:graphicimage.../></f:facet> 8 <f:facet name="fastrewind"><h:graphicimage.../></f:facet> 9 </ice:datapaginator> Figure 7.13: ICEfaces data table with paginator In order to make a column sortable, attributes sortcolumn and sortascending of data table have to be set. Then, the <ice:commandsortheader> component has to be put inside the <ice:column> component. After that, sorting code in managed bean has to be written including a comparator for data model. For multi-column sorting the code might be very complicated. 1 <ice:column id="columnstate"> 2 <f:facet name="header"> 3 <ice:commandsortheader columnname="state" arrow="true"> 4 <h:outputtext id="columnheaderstate" value="state" /> 5 </ice:commandsortheader> 6 </f:facet> 7 8 <h:outputtext value="#{record.state}" /> 9 <f:facet name="footer"> 10 <h:outputtext id="columnfooterstate" value="state" /> 11 </f:facet> 12 </ice:column> 73

81 7. ITERATION COMPONENTS ICEfaces data table does not provide any means for filtering column. Row selection is implemented using the <ice:rowselector> component inside a column. It supports both single selection and multi selection. 1 <ice:datatable...> 2 <ice:column> 3 <ice:rowselector.../> 4 <f:facet name="header"> 5 <ice:outputtext.../> 6 </f:facet> 7 <ice:outputtext.../> 8 </ice:column> </ice:datatable> 74

82 8 Charts In web applications working with large amounts of data it is usually not enough to display them in tables or other iteration components. In such cases, charts come in handy. Rich- Faces do not include any prepared charts components. However, it is possible to reuse existing Java charting libraries, such as JFreeChart, with combination of <a4j:mediaoutput> components that is suitable for displaying dynamically generated images. Another option is to use some JavaScript library creating charts using canvas or SVG. Some JavaScript libraries (e.g. Flotr) are also packaged as JSF components (project JSFlot). However, these solution are not tested and supported with RichFaces. 8.1 Charts in PrimeFaces PrimeFaces contains Flash-based chart components using YUI library. There these types of charts available: bar chart; column chart; line chart; pie chart; stacked bar chart; and stacked column chart. It is really simple to create charts in PrimeFaces. First, a model has to be created. Pie chart in PrimeFaces require a special list-like model represented by class PieChartModel. 1 public class ChartBean { 2 private PieChartModel sales; 3 4 public ChartBean() { 5 sales = new PieChartModel(); 6 sales.set("brand 1", 540); 7 sales.set("brand 2", 325); 8 sales.set("brand 3", 702); 9 sales.set("brand 4", 367); 10 } } After that, component has to be placed on a page. The model attribute should be bound to managed bean s property with model. The component has to have width and height 75

83 8. CHARTS attributes specified, otherwise nothing will be rendered on the page and a JavaScript error will occur. 1 <p:barchart id="barchart" model="#{chartbean.births}" width="400px" 2 height="250px"/> Figure 8.1: PrimeFaces pie chart component All other chart components in PrimeFaces can be used with another type of model a model for Cartesian data represented by class CartesianChartModel. 1 public class ChartBean { 2 private CartesianChartModel births; 3 4 public ChartBean() { 5 births = new CartesianChartModel(); 6 ChartSeries birthsboys = new ChartSeries("boys"); 7 birthsboys.set("2006", 120); ChartSeries birthsgirls = new ChartSeries("girls"); 11 birthsgirls.set("2006", 52); births.addseries(birthsgirls); 15 births.addseries(birthsboys); 16 } } When the model is created, it is very simple to us whichever chart component: 1 <p:barchart model="#{chartbean.births}" width="400px" height="250px"/> 2 <p:columnchart model="#{chartbean.births}" width="400px" height="250px"/> 3 <p:linechart model="#{chartbean.births}" width="400px" height="250px"/> 4 <p:stackedbarchart model="#{chartbean.births}" width="400px" height="250px"/> 5 <p:stackedcolumnchart model="#{chartbean.births}" width="400px" 6 height="250px"/> 76

84 8. CHARTS Figure 8.2: PrimeFaces bar chart Although the PrimeFaces charts are based on Flash, they are highly customizable. Styling is done using JavaScript because, obviously, it is not possible to use CSS. Style attribute of a chart component should contain name of a JavaScript object. The following example demonstrates how to set chart s border and legend, full list of all options that can be set can be found in PrimeFaces Developer Guide. [22, p. 63] 1 <script type="text/javascript"> 2 var chartstyle = { 3 border : { color : red, size : 3 }, 4 legend : { display : "left" } 5 } 6 </script> 7 8 <p:piechart id="piechart" model="#{chartbean.sales}" style="chartstyle"/> PrimeFaces charts have built-in support for Ajax polling and live data displaying. In order to use this feature, attribute live has to be set to true and refreshinterval attribute should contain time how often the component should be updated (in milliseconds). 1 <p:piechart id="piechart" model="#{chartbean.sales}" style="chartstyle" 2 live="true" refreshinterval="4000"/> Like in RichFaces, it is possible to create static charts using JFreeChart. In such case, <p: graphicimage> component has to be used for generated image. 8.2 Charts in OpenFaces All OpenFaces charts are based on JFreeChart library. There is support for three chart types in OpenFaces library: pie, bar, and line charts. The API of OpenFaces charts is unified all types of charts use the same tag (<o:chart>) and the same model (represented by class org.openfaces.component.chart.chartmodel). OpenFaces Developer Guide [16, section Chart] shows how to create a simple chart model: 77

85 8. CHARTS 1 public ChartModel getpopulation() { 2 Map data = new HashMap(); 3 data.put("london, United Kingdom", new Integer( )); 4 data.put("berlin, Germany", new Integer( )); 5 data.put("madrid, Spain", new Integer( )); 6 data.put("rome, Italy", new Integer( )); 7 data.put("paris, France", new Integer( )); 8 9 PlainSeries series = new PlainSeries(); 10 series.setdata(data); 11 series.setkey("largest cities of the European Union"); PlainModel model = new PlainModel(); 14 model.addseries(series); 15 return model; 16 } When the model is prepared, the <o:chart> component can be placed on a page like this: 1 <o:chart model="#{ochartbean.population}" view="bar" 2 titletext="largest Cities of the European Union by Population" 3 legendvisible="true" width="800"/> The code above will render a bar chart. Pie chart and line chart can be rendered using the same code with just changing view attribute to pie or line. Alternatively, the type of chart can be specified by using one of <o:piechartview>, <o:linechartview>, or <o :barchartview> components inside the <o:chart> component, e.g.: 1 <o:chart model="#{ochartbean.population}" 2 titletext="largest Cities of the European Union by Population" 3 legendvisible="true" width="800"> 4 <o:linechartview/> 5 </o:chart> Figure 8.3: OpenFaces line chart In this case, developer has more options for customization of chart component. For instance, it is possible to turn off labels and turn on tooltip instead: 78

86 8. CHARTS 1 <o:chart model="#{ochartbean.population}" 2 titletext="largest Cities of the European Union by Population" 3 legendvisible="true" width="800"> 4 5 <o:piechartview labelsvisible="false" 6 tooltip="#{sector.key} - #{sector.value}"/> 7 8 </o:chart> Figure 8.4: OpenFaces pie chart with default settings Line and bar charts can be vertically or horizontally oriented. To specify the orientation, the orientation attribute has to be set to vertical (default) or horizontal. Charts can be also displayed in 3D mode. To use this feature, attribute enable3d has to be set to true. 1 <o:chart...> 2 <o:barchartview enable3d="true"/> 3 </o:chart> Since OpenFaces charts are generated on the server side, it is not possible to use CSS for styling. However, there are few attributes for setting visual properties of charts such as backgroundpaint, titlepaint, showgradient, or wallcolor. Much more information about styling OpenFaces charts, grid lines, labels, tooltips, context menus, etc. can be found in OpenFaces Developer Guide. [16, section Chart] 8.3 Charts in ICEfaces Charts in ICEfaces are static and are implemented using JCharts library and thus they are very similar to those generated with JFreeChart. ICEfaces support these types of charts: 79

87 8. CHARTS area; areastacked; bar; barclustered; barstacked; line; pie2d; pie3d; point; stock; and custom. All these types of charts use the same underlying data model which can be for example standard Java list. Moreover, it is possible to define data directly on page. To use the ICEfaces charts, it is necessary to map Faces Servlet to /icefaces/*, otherwise charts will not be rendered on the page. 1 <servlet> 2 <servlet-name>faces Servlet</servlet-name> 3 <servlet-class>javax.faces.webapp.facesservlet</servlet-class> 4 <load-on-startup>1</load-on-startup> 5 </servlet> 6 <servlet-mapping> 7 <servlet-name>faces Servlet</servlet-name> 8 <url-pattern>/icefaces/*</url-pattern> 9 </servlet-mapping> After that, it is possible to use the <ice:outputchart> component. 1 <ice:outputchart data="10, 30, 40, 33" width="300" height="300" type="pie3d"/> Figure 8.5: ICEfaces 3D pie chart 80

88 When the chart type is set to custom, it is possible to create charts of mixed type. 8. CHARTS Figure 8.6: ICEfaces custom chart mixing bar chart and line chart, picture from [14] 81

89 9 Validation Validation of user s inputs is a very important part of creating a rich internet application. Validations in JSF are performed in third phase of JSF lifecycle (called Process validations). If the validation fails, the fourth and fifth phase (Update model values and Invoke application) are skipped. 9.1 Faces Validation Tags <f:validatelongrange>, <f:validatelength>, etc. were used in JSF 1.x for validation. Although this approach worked well, there was a need for validating using Ajax or validating using Hibernate Validator which represented a general approach to validating across all tiers of an enterprise application. The value in the following sample would be validated in order to ensure that the string s length is between 4 and 10 including. 1 <h:inputtext value="#{bean.value}"> 2 <f:validatelength minimum="4" maximum="10"/> 3 </h:inputtext> 9.2 Bean Validation Java EE 6 came with a new standard JSR-303 Bean Validation of which Red Hat is the specification lead. Hibernate Validator 4.x became the reference implementation of JSR-303. JSR- 303 defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the metadata through the use of XML validation descriptors. The API is not tied to a specific application tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client application developer. The sample from previous section can be rewritten like in the following sample. The most noticeable change is the usage of an instead of <f:validatelength> tag. Otherwise, the two samples are equivalent. Although JSF validation tags are supported in JSF 2, it is recommended to use Bean validation. 2 public class Bean { 3 private String value; 4 = 4, max = 10) 6 public String getvalue() { 7 return value; 8 }

90 9. VALIDATION 10 } 1 <h:inputtext value="#{bean.value}"/> 9.3 Client Side Validation The added value of JSF component libraries is support for client side validation. Firing HTML or Ajax request for each input in a form might overload the server. However, when the inputs are first validated on client and after that they are sent to the server, the load and traffic is much lower. To use client-side validation in RichFaces, the behavior <rich: validator> has to be attached to validated input. The former example rewritten using the client-side validation would be very similar: 2 public class Bean { 3 private String value; 4 = 4, max = 10) 6 public String getvalue() { 7 return value; 8 } } 1 <h:inputtext value="#{bean.value}"> 2 <rich:validator event="keyup"/> 3 </h:inputtext> Although the last two examples are very similar, there is a huge difference in functionality. In the later example, a JavaScript validation would be executed. If no client-side validation method exists for a registered server-side validator, Ajax fallback is used. The <rich: validator> behavior invokes all available client-side validators. If all the client-side validators return valid, RichFaces performs an Ajax request to invoke the remaining validators on the server side. [15, section Validation] In OpenFaces, there is also a feature called client-side validation. However, it does not work for fields annotated with Bean validation annotations, only for field with attached JSF validator tags. To enable the feature, a context parameter has to be set in web.xml: 1 <context-param> 2 <param-name>org.openfaces.validation.clientvalidation</param-name> 3 <param-value>onsubmit</param-value> 4 </context-param> When the context parameter is set, every input field with attached JSF validator tag is validated on the client before the form is submitted. It is possible to set validation not only for 83

91 9. VALIDATION whole application but also for a form or even for an individual component. Single component can be validated with following code: 1 <h:inputtext required="true" onchange="o$.validate(this);"/> Particular form will be validated if <o:clientvalidationsupport> component is attached to the form. 1 <h:form> 2 <o:clientvalidationsupport clientvalidation="onsubmit" 3 usedefaultclientvalidationpresentation="true" 4 usedefaultservervalidationpresentation="true"/> <h:inputtext value="#{bean.value}"> 8 <f:validatedoublerange minimum="4"/> 9 </h:inputtext> </h:form> There is no support for client-side validation in PrimeFaces nor ICEfaces. However it is possible to validate fields with Ajax in ICEfaces using the attribute partialsubmit set to true. 9.4 Cross-field Validation RichFaces contain the <rich:graphvalidator> component which is used to wrap a set of input components related to one object. The object defined by the component <rich: graphvalidator> can then be completely validated. The validation includes all object properties, even those which are not bound to the individual form components. Validation performed in this way allows for cross-field validation in complex forms. [15, section rich:graphvalidator object validation] Internally, RichFaces clone validated object in order to interrupt lifecycle correctly after the Process validations phase. 1 <rich:graphvalidator value="#{bean}" id="gv"> 2 <h:outputtext value="enter new password:" /> 3 <h:inputsecret value="#{bean.password}" id="pass" /> 4 <br/><br/> 5 <h:outputtext value="confirm the new password:" /> 6 <h:inputsecret value="#{bean.confirm}" id="conf" /> 7 <a4j:commandbutton value="store changes" action="#{bean.storenewpassword}" /> 8 </rich:graphvalidator> 3 public class Bean implements Cloneable, Serializable{ = 5, max = 15, message = "Wrong size for password") 84

92 5 private String password=""; = 5, max = 15, message = "Wrong size for confirmation") 7 private String confirm=""; 8 = "Different passwords entered!") 10 public boolean ispasswordsequals() { 11 return password.equals(confirm); 12 } VALIDATION 14 public void storenewpassword() { 15 FacesContext.getCurrentInstance().addMessage(null, new FacesMessage( FacesMessage.SEVERITY_INFO, "Succesfully changed!", "Succesfully changed!")); 16 } public Object clone() throws CloneNotSupportedException { 20 return super.clone(); 21 } // getters and setters omitted 24 } The next specification of JSF will probably contain some support for cross-field validation. 9.5 Messages The <h:message> and <h:messages> are standard JSF components for displaying messages. The <h:message> component displays only one message for a particular component while <h:messages> display all messages that occured. Although both of these components work fine for HTTP requests, a placeholder is needed when the validation is performed using Ajax requests. This is related to the fact that with Ajax it is much easier to replace elements in DOM than create them. To work around this drawback, JSF component libraries implement their own messages. The <rich:message> component displays one message for one component specified in for attribute. Unlike standard <h:message> component, RichFaces message contains also an icon and is highly customizable. Analogically, the <rich:messages> component will display all messages for all components. 1 <h:outputtext value="age:" /> 2 <h:inputtext label="age" id="age" required="true" value="#{userbean.age}"> 3 <f:validatelength minimum="1" maximum="10" /> 4 </h:inputtext> 5 <rich:message for="age" ajaxrendered="true"/> 85

93 9. VALIDATION Figure 9.1: RichFaces message PrimeFaces contain a component called <p:growl>, inspired by Mac s growl component. Growl is a replacement for <h:messages> and thus it is very simple to use it. By default each message is hidden after six seconds. However, it is possible to cancel this behavior by setting attribute sticky to true. It is also possible to change the duration of displaying growl. This can be done using attribute life (in milliseconds). Figure 9.2: PrimeFaces growl component with three messages OpenFaces displays an image over an invalid component and applies a CSS style to it. This kind of error messaging does not affect the page layout and, therefore, can be used as default validation error presentation. Figure 9.3: Standard styling of input after validation error in OpenFaces In order to customize validation output, it is possible to use <o:floatingiconmessage> component. 1 <h:inputtext id="requiredinput" required="true"/> 2 <o:floatingiconmessage for="requiredinput" style="border: 2px solid red;"/> 9.6 Captcha PrimeFaces contain a captcha component based on recaptcha a popular online antibot service that helps digitalize books. There are four themes and it is possible to select 86

94 9. VALIDATION component s language as well. To use the component, user needs to generate a key pair on recaptcha web site. 1 Then keys have to be set in web.xml: 1 <context-param> 2 <param-name>primefaces.private_captcha_key</param-name> 3 <param-value>...</param-value> 4 </context-param> 5 <context-param> 6 <param-name>primefaces.public_captcha_key</param-name> 7 <param-value>...</param-value> 8 </context-param> When keys are set, the component can be placed on a web page. When a user types in a wrong string, a validation message will be displayed. 1 <p:captcha id="captcha" value="#{bean.value}"/> Figure 9.4: PrimeFaces captcha 1. recaptcha home page, 87