White Paper. JavaServer Faces, Graphical Components from Theory to Practice

White Paper JavaServer Faces, Graphical Components from Theory to Practice

JavaServer Faces, Graphical Components from Theory to Practice White Paper ILOG, April 2005 Do not duplicate without permission. ILOG, CPLEX and their respective logotypes are registered trademarks. All other company and product names are trademarks or registered trademarks of their respective holders. The material presented in this document is summary in nature, subject to change, not contractual and intended for general information only and does not constitute a representation.

JavaServer Faces, Graphical Components from Theory to Practice White Paper April 2005 Table of Contents THE CHALLENGE...2 WHAT IS JAVASERVER FACES?...2 CREATING A SIMPLE JSF COMPONENT...4 STEP 1: THE COMPONENT JAVA CLASS...5 STEP 2: THE RENDERER...6 STEP 3: THE TAG CLASS...6 STEP 4: THE TAG LIBRARY DEFINITION (TLD)...8 STEP 5: THE JSF CONFIGURATION FILE...9 CREATING A JSF GRAPHICAL COMPONENT... 10 Component... 13 Renderer... 13 Proxies... 13 Script Dependencies... 14 Scripting and State Synchronization... 14 Component Dependencies... 14 MAKE FUTURE INTEGRATION EASIER IN IDE... 16 ILOG JVIEWS AND JSF... 17 USING ILOG JVIEWS DIAGRAMMER FRAMEWORK FACES... 17 The View... 17 Manager View... 18 Installing Interactors... 19 Adding an Overview... 19 Adding a Pan Tool and a Zoom Tool... 20 Improving the Pages... 20 CHARTS AND GANTT DISPLAYS... 21 CONCLUSION... 22 REFERENCES... 23 FURTHER READING... 23-1 / 23 -

JavaServer Faces, Graphical Components from Theory to Practice The Challenge The Java platform offers a proven model for creating and deploying portable applications. However, the demand for easy-to-deploy Web applications -- a.k.a. thin clients -- remains strong in most industries. JavaServer Faces (JSF) makes it possible to build interactive Web clients more easily than with other technologies, including JavaServer Pages and Apache Struts. JSF clearly separates application logic from the graphical user interface (GUI), improving the maintainability of Web applications and providing a framework for developing and reusing Web interface components. Despite the standard framework provided by JSF, there still remain several pitfalls for anyone developing their first custom JSF components. Additionally, even if this framework offers good support for standard human-machine interfaces, application developers want greater productivity and more sophisticated off-the-shelf visualization components. In this paper, we explain how to create a graphical JSF component that cannot be easily built using pure HTML, and how ILOG JViews can help Web developers create attractive, yet highly functional, JSF applications. What is JavaServer Faces? JavaServer Faces (JSF) is a standard server-side framework that simplifies the construction of the presentation layer of Web applications. Developers can assemble reusable GUI components to create Web pages, bind these components to a data source, and process client-side events with server-side event handlers. By following this specification, component vendors can write components that can be cleanly integrated into the JSF runtime framework and integrated development environments (IDEs) that are JSF compliant. JSR 127 (1), which defines the JSF framework, comes with a Reference Implementation that provides basic GUI components, such as input fields and buttons. For the most part, these JSF components correspond directly to the HTML components and tags available in the HTML 1.4 specification. This set of relatively simple components is sufficient for many Web applications. However, many applications, like supervision or monitoring, require more complex data display and interaction such as charting, diagramming and mapping. HTML is limited in its ability to render complex graphics widgets like these. The solution requires - 2 / 23 -

that the server-side components deliver images to the client. However, this brings its own problems because interaction with basic HTML images is limited. Finally, JavaScript must be used to enable the client-side interactions that allow the user to navigate and interact with the data. Many Web application developers are now migrating to JSF, but they are finding the set of predefined JSF GUI components limited to basic DHTML widgets. Advanced applications, such as supervision and business process monitoring, need advanced visualization components that are compatible with the JSF framework. The standardization brought by the JSF framework makes it easy to develop custom web GUI components that can be reused by application developers. In addition, Web component vendors are now able to provide more sophisticated components, with the assurance that Web application developers can easily take advantage of these components. Such JSF GUI components must be integrated and deployed cleanly into the JSF runtime framework, and at design time into IDEs that provide JSF support. The characteristics of a graphical JSF component require not only the generation of DHTML, but also some extra support for image generation and client-side interaction. We will illustrate this with an example of a charting component that is designed to provide graphical charts, as well as various client-side navigation and interaction facilities. Finally, we show the steps required to integrate the charting component into a JSF enabled IDE. By understanding the design of the charting component, you will better know how a graphical JSF component can be implemented and, hopefully, allow you to develop your own custom JSF graphical components. - 3 / 23 -

Creating a Simple JSF Component In the following section, we describe the steps for developing a very simple JSF component that imports CSS into an HTML page. The description and code samples for this simple component will serve in the background as we develop our advanced JSF charting component in the subsequent sections. The figures below show how the component is used and the result we will get. JSP <html> <f:view> <head> <custom:css value= data/style.css link= true /> </head> [ ] </f:view> </html> JSP <html> <f:view> <head> <custom:css value=.class{background:#cccccc link= true /> </head> [ ] </f:view> </html> HTML <html> <head> <link type='text/css' rel='stylesheet' href= data/style.css' /> </head> [ ] </html> HTML <html> <head> <style>.class= background:#cccccc </style> </head> [ ] </html> The main benefit of using such a component is that one can change the complete look of the page by changing the component value with a JSF action. A JSF component consists of several Java classes and configuration files. In order to create a custom JSF component, you need to: Step 1: Develop a Java class that extends one of the JSF base component classes. Step 2: Develop a renderer for the default render kit. - 4 / 23 -

Step 3: Develop a Java class that describes the tag that will be used in the JSP page. Step 4: Write a Tag Library Definition file. Step 5: Write the JSF configuration file. We will illustrate each step in turn below. Step 1: The Component Java Class The component class is responsible for managing the properties that represent the component s state. Therefore, we must choose an appropriate base class for the component based on its behavior, such as an input or output. import javax.faces.component.*; public class CSSComponent extends UIOutput { private Boolean link; public String getfamily() { return "faces.cssfamily"; public boolean islink() { if (link!= null) return link.booleanvalue(); ValueBinding vb = getvaluebinding("link"); if (vb!= null) { Boolean bvb = (Boolean) vb.getvalue(facescontext.getcurrentinstance()); if (bvb!= null) return bvb.booleanvalue(); return false; public void setlink(boolean link) { this.link = new Boolean(link); public Object savestate(facescontext context) { return new Object[] { super.savestate(context), link ; public void restorestate(facescontext context, Object stateobj) { Object[] state = (Object[]) stateobj; super.restorestate(context, state[0]); link = (Boolean) state[1]; The component described here extends javax.faces.component.uioutput to display a URL pointing to a style sheet file or the contents of an inline style sheet. The component can be used to switch from one style sheet to another in a JSF action. The link property specifies the type of the value, either a URL or the inline style. The component must also be able to store and restore its state between requests to the server using an object processed by the JSF framework. The state of a component consists of the significant property values that are needed to rebuild the object. The JSF framework automatically calls the savestate and restorestate methods, which we have implemented in our component to achieve this goal. - 5 / 23 -

Step 2: The Renderer The renderer has two roles. First, the renderer is responsible for emitting an appropriate HTML fragment that will render the component in the client. Usually, this HTML fragment will consist of HTML tags that are suitable for rendering in general Web browsers. This phase of the JSF lifecycle is called the encoding or render response phase. This rendering phase can also be used to emit JavaScript code that can be used to enhance client-side interaction. The second role of a renderer is to decode the data that comes from the client to update the server-side component state (for example, the text that the user entered into a text field). The standard render kit is mandatory, but other renderer kits can be provided to offer an alternate client-side representation or language such as SVG (2). import javax.faces.component.uicomponent; import javax.faces.context.facescontext; import javax.faces.context.responsewriter; import javax.faces.render.renderer; public class CSSRenderer extends Renderer { public void encodeend(facescontext context, UIComponent component) throws IOException { super.encodeend(context, component); if (component instanceof CSSComponent) { CSSComponent csscomponent = (CSSComponent) component; String css = (String)cssComponent.getValue(); boolean islink = csscomponent.islink(); if (css!= null) if (islink) context.getresponsewriter().write("<link type='text/css' rel='stylesheet' href='" + css + "'/>"); else context.getresponsewriter().write("<style>\n" + css + "\n<style/>\n"); The renderer implemented here chooses the type of the CSS to be shown in the HTML page by checking the link property of the component. Step 3: The Tag Class Again, the JSF framework provides base classes you may want to extend to write the tag associated with the component. The tag class is responsible for: Defining the component type and the rendering type of the component that will be used in the faces-config.xml file that we will describe in the next section Creating the JSF component (handled by the JSF framework) and passing attributes that are contained in the JSF tag to initialize the component - 6 / 23 -

import javax.faces.webapp.uicomponenttag; public class CSSTag extends UIComponentTag { private String value; private String link; public String getcomponenttype() { return "faces.csscomponent"; public String getrenderertype() { return HTML.LinkOrInlineRenderer"; protected void setproperties(uicomponent component) { super.setproperties(component); Application app = getfacescontext().getapplication(); if (value!= null) if (isvaluereference(value)) component.setvaluebinding("value", app.createvaluebinding(value)); else component.getattributes().put("value", value); if (link!= null) if (isvaluereference(link)) component.setvaluebinding("link", app.createvaluebinding(link)); else component.getattributes().put("link", new Boolean(link)); public String getlink() { return link; public void setlink(string link) { this.link = link; public String getvalue() { return value; public void setvalue(string value) { this.value = value; The tag provides setters and getters to manage the link and value attributes. When the component is created, the setproperties method is called to initialize its properties from the tag attributes. Each tag attribute can be either a literal value or a binding to a bean property. - 7 / 23 -

Step 4: The Tag Library Definition (TLD) The TLD is an XML file that describes the tag by associating the name of the tag with the corresponding Java class. The TLD also describes the allowed attributes of the tag. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" "http://java.sun.com/dtd/webjsptaglibrary_1_2.dtd"> <taglib> <tlib-version>1.0</tlib-version> <jsp-version>1.2</jsp-version> <short-name>custom</short-name> <uri>http://www.ilog.com/jviews/tlds/css.tld</uri> <description>this tag library contains a tag for a sample custom JSF Component.</description> <tag> <name>css</name> <tag-class>path.to.csstag</tag-class> <description>a component that displays the style inline or a link a to a css file</description> <attribute> <name>id</name> <required>false</required> <rtexprvalue>false</rtexprvalue> <type>java.lang.string</type> <description>the id of this component.</description> </attribute> <attribute> <name>binding</name> <required>false</required> <rtexprvalue>false</rtexprvalue> <type>java.lang.string</type> <description>the value binding expression linking this component to a property in a backing bean. If this attribute is set, the tag does not create the component itself but retrieves it from the bean property. This attribute must be a value binding.</description> </attribute> <attribute> <name>value</name> <required>true</required> <rtexprvalue>false</rtexprvalue> <type>java.lang.string</type> <description>the inline css text or the url to the css file to link.</description> </attribute> <attribute> <name>link</name> <required>false</required> <rtexprvalue>false</rtexprvalue> <type>java.lang.string</type> <description>whether the value is a link or the inline style.</description> </attribute> </tag> </taglib> This TLD defines a tag named css that is bound to the CSSTag class. It also declares the link and value tag attributes. - 8 / 23 -

Step 5: The JSF Configuration File In order to integrate a JSF component into the framework, you must provide a configuration file called faces-config.xml. This file associates component types and renderer types, which are used in the JSP custom tag handler, to their corresponding Java class. This file also describes the renderer that should be used with each component. <!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN" "http://java.sun.com/dtd/web-facesconfig_1_0.dtd"> <faces-config> <component> <component-type>faces.csscomponent</component-type> <component-class>path.to.csscomponent</component-class> <component-extension> <component-family>faces.cssfamily</component-family> <renderer-type>html.linkorinlinerenderer</renderer-type> </component-extension> </component> <render-kit> <renderer> <component-family>faces.cssfamily</component-family> <renderer-type> HTML.LinkOrInlineRenderer </renderer-type> <renderer-class>path.to.cssrenderer</renderer-class> </renderer> </render-kit> </faces-config> This file defines the faces.cssfamily component family. In our example, the family is made of a single component of type faces.csscomponent. This type is bound to the CSSComponent class. Finally, the renderer of type HTML.LinkOrInlineRenderer, which is implemented by the CSSRenderer class, is associated with the faces.cssfamily family. You can also provide additional information if you want your component integrated into a JSF-enabled IDE. In the case of the Sun Creator IDE, you need to provide an XML configuration file named sun-faces-config.xml. This configuration file describes the properties of the component that should to be exposed in the IDE, as well as other design-time information. For more information on Sun Creator, refer to the product description on the Sun Microsystems website (3). Now that we have seen how to create a simple JSF component, we will now look at how to create a graphical JSF component. For a more detailed description of how to build a custom JSF component, refer to the Java J2EE tutorial (3). - 9 / 23 -

Creating a JSF Graphical Component Now, we will follow the same basic steps to design an advanced JSF graphical component. For our example, we will use a charting component similar to the ILOG JSF Charting component, which provides a visual representation of the distribution of data values across a set of categories. The chart is able to display a data set with various representations, including bars, pie charts and bubble charts. The JSF Charting component has two initial design constraints: 1. We already have a Java charting bean component that has all of the graphical presentation capabilities we want. This component can display a wide range of charts and is highly customizable. Ideally, we want to leverage this bean component and use its capabilities to form the basis of our JSF component. 2. Common JSF applications need to reload the entire page to refresh the view. This behavior can be appropriate for form-based applications, but in many cases, not for highly graphical user interfaces. Therefore, in order to provide a better user experience, our JSF charting component must support some simple navigation without refreshing the entire page. In order to satisfy these requirements, the following solution has been created: The JSF charting component will manage the chart bean component. This includes creating the chart bean by customizing the bean and making the bean available for server-side actions. Rendering the JSF component will be done in two phases: o The JSF renderer will generate an <img> tag and a set of JavaScript objects (Figure 1). o The client will request an image from the server. This is done by a servlet that retrieves the chart bean and generates an image using methods provided by the chart (Figure 2). Any further user interactions (zooming, panning, change of a style sheet, etc) that change the chart image will only result in an incremental refresh of the chart image. If the client-side action requires more than just an update of the chart image, the page will be submitted (Figure 3). - 10 / 23 -

The following diagrams describe the architecture of this solution. Client JSP Server JSF Request Process reques 1 JSP Tag respons 3 JSF Component Render er 2 Session Chart Bean 1. Create and initialize properties. 2. Create and customize the chart and make it available for server-side actions. 3. Render the chart. Figure 1: Request to the JSF framework Client HTML Image reques t respons Server Image servlet JavaScript Session Chart Bean Figure 2: Request to the servlet to obtain an image. - 11 / 23 -

Client Server HTML JavaScript Type of request Image reques Page Reque Image servlet Session JSF Chart Bean Figure 3: Either a page request or an image request. The JSF Charting component is also accompanied by a set of additional JSF components: Overview: An overview displays a global view of the chart and a rectangle representing the actual chart view. This component also allows the user to pan the visible area. Legend: A legend component shows information about the data set being displayed. The legend can also be displayed in the chart itself, depending on the style of the data displayed. Interactors: Client-side interactors, such as pan and zoom of the chart image, are also provided. These interactions can be seen as client-side interactions, meaning that interacting with the chart will not reload the entire page as is the case for a regular JSF interaction. To render the chart component, you simply have to use the chartview tag: <jvcf:chartview id="c" style="width:500px;height:300px" /> The data is displayed as an image on the HTML page. The image is built by a servlet in response to an HTTP request that includes various parameters that - 12 / 23 -

specify the resulting image, specify generation of an image map, specify generation of an inline legend, and so on. The resulting image is then inserted into the client-side DOM, and the only part of the page that is refreshed is the image itself. Let s now look at some differences between a simple custom JSF component and the advanced charting component. Component The JSF chart component class is very much like a standard component, with the addition of a chart property that gives access to the chart bean responsible for generating the image displayed in the HTML page. The JSF component can retrieve this chart bean locally through a value binding or in the current session. When the JSF charting component is the centerpiece of an application, optional JSF components, such as an overview or a legend, can be connected to the main chart to display additional information. <jvcf:chartzoominteractor id="chartzoominteractor" XZoomAllowed="true" YZoomAllowed="true" /> <jvcf:chartview id="chartview" chart= #{mybean.chart servlet="demo.imagemapservlet" interactorid="chartzoominteractor" width="500" height="300" stylesheets="/data/line.css" waitingimage="data/images/wait.gif" imageformat="png" /> <jvcf:chartoverview id="chartoverview" style="height:100;width:150px" viewid="chartview" linewidth="3" linecolor="red" /> <jvcf:chartlegend id="legendview" viewid="chartview" width="400" height="180" layout="vertical" waitingimage="data/images/wait.gif" /> Renderer The renderer is the major complexity of this JSF implementation. As we mentioned previously, the renderer does not generate simple HTML, but rather DHTML that consists of HTML (the <IMG> tag) and JavaScript proxies. Proxies A proxy is an instance of a JavaScript class responsible for managing the display of the component image on the client. This object is the client representation of the server-side Java component class and has the same properties. Each component on the page -- the chart and its companions -- has a proxy instance. - 13 / 23 -

A good practice when rendering JavaScript is to use the facescontext.getexternalcontext().encodenamespace(name) method on every JavaScript variable. It will make future integration of the component into a JSR168 (4) -compliant portlet environment easier. Script Dependencies To instantiate a proxy on the client, JavaScript support libraries must be imported onto the page. To keep the client as thin as possible, the JavaScript libraries are modularized based on the proxy classes they support. Therefore, each proxy class needs a different, and possibly overlapping, set of libraries to be imported. One of the tricky parts of the chart rendering is the phase that emits these script libraries. The renderer of each component declares which library it requires, and when emitting the library references, it needs to be aware of the previously emitted libraries to avoid duplication. This is done by a script manager that only exists during page rendering. Each time a renderer wants to emit the set of library imports, it gives the list to the script manager that filters out the libraries that have already been emitted. Scripting and State Synchronization The purpose of the client-side proxies is to allow scripting and avoid unnecessary page refresh. Once the chart is rendered, the proxies are available on the clientside to dynamically install interactors and to show or hide the image map. The proxy objects are also available for regular JSF components that support JavaScript mouse event handling. <jvcf:chartview id="chartview".. /> <h:selectbooleancheckbox id="genimagemap" onclick="chartview.setgenerateimagemap(this.checked? true : false, true);" /> The problem with locally modifying the component s client-side proxy is that its state will no longer be synchronized with that of the Java component on the server. To solve this, the proxies use a hidden input tag (<INPUT TYPE="HIDDEN">) to save the new state on the client. When a standard JSF action is performed and the page is submitted, this hidden state will be decoded by the renderer so that the client and server are synchronized. This behavior requires special decoding behavior in the renderer class. The standard decode method is enhanced to decode the state that comes from the client and update the server-side component state. Component Dependencies The connection between the chart and its associated component is made by ID references or binding. To allow flexible page design, a component can be referenced before it is actually rendered. Therefore at rendering time, if a component property references another component that is not already rendered, the emission of the JavaScript code that resolves this dependency on the client is - 14 / 23 -

delayed until the referenced component is rendered. This work is done by a dependency manager. To illustrate this, let s look at a typical case that involves an overview that references a chart. Example: <jvcf:overview viewid="chart" [...] /> <jvcf:chartview id="chart" [...] /> There are two cases: The referenced chart component is already rendered, so there is no problem: Example: JSP: <jvcf:chartview id="chart" [...] /> <jvcf:overview viewid="chart" id="overview" [...] /> render: [...] var chart = new IlvChartViewProxy (.. ); [...] var overview= new IlvFacesOverviewProxy (.. ); overview.setview(chart); [...] The referenced chart component is not rendered before the dependent overview component. In this case, a component-creation listener is registered on the dependency manager. When the referenced chart component is eventually rendered, its renderer notifies the dependency manager of its creation. At this point, the code needed to resolve the dependency will be emitted: Example JSP: <jvf:overview viewid="chart" id="overview" [...] /> <jvdf:chartview id="chart" [...] /> render: [...] var overview = new IlvFacesOverviewProxy (.. ); [...] var chart = new IlvChartViewProxy (.. ); overview.setview(chart); [...] - 15 / 23 -

Make Future Integration Easier in IDE One of the goals of developing JSF components is the ability to use them in any JSF compliant integrated development environment (IDE). Nevertheless, JSF compliance is not always enough to guarantee that such design-time integration will work. Here are some simple ideas to keep in mind during the development of your JSF component to facilitate its future integration into an IDE. First, your custom JSF component should provide a basic HTML rendering. During design time, JSF IDEs cannot render dynamic graphical components that require live data or app server connections. Therefore, components that have a complex or unconventional (e.g. not HTML) rendering should use Beans.isDesignTime() to determine whether they should provide a basic HTML representation or the true component rendering. Another design time issue is the positioning and dimensioning of the component. Sun Creator (5) uses the style attribute, while IBM WSAD (6) works with height and width properties. A component that can be resized, such as an image, should be able to handle both ways of defining the size. Sun s Java Studio Creator in Design mode with a JSF Chart component Finally, for integration with IDEs, the component must provide extra information that has yet to be defined by the JSF specification. Unfortunately, each IDE currently requires special handling to integrate your component: an XML file for Sun Creator, an Eclipse plug-in for IBM WASD, and so on. A main goal of the next JavaServer Faces JSR (v2.0) will be to specify the additional metadata formats. - 16 / 23 -

ILOG JViews and JSF As we have seen, custom JSF components can be created and added to the standard framework. But as always in application development, we need to minimize the effort for putting together sophisticated applications. In this respect, ILOG has been an early adopter of JSF, and since Version 6.5, the ILOG JViews product line has come with several ready-to-use JSF components. They have been created and optimized for the different types of displays available with the product. Basically, there is a set of JSF tags and components for generic diagrams, charts and Gantt charts. These components are based on an architecture similar to the one described above, and for easier use, several interactors and tools have been created. For example, ILOG JViews Diagrammer components are available as a set of classes and a tag library. A set of renderers generates DHTML code for displaying the components. The components also use the servlet technology to generate images to be transferred to the client. JSF components offer generic graphical views, additional visual components and interactors such as pan, zoom, selectors and overview. Using ILOG JViews Diagrammer Framework Faces Different approaches can be taken for adding ILOG JViews Diagrammer JSF components (also called Framework Faces) to a new Web page, but all of them take advantage of the prepackaged components available in the product. The following paragraphs illustrate the main concepts. The View The first and simplest page that can be made with a JViews Framework Faces component is an empty view: <jvf:view style="width:500 px; height:300 px;" /> This produces a 500x300-pixel view. The namespace jvf, which stands for JViews Framework Faces, must be declared in the page: <%@ taglib uri="http://www.ilog.com/jviews/tlds/jviews-framework-faces.tld" prefix="jvf" %> - 17 / 23 -

An alternative to specifying the size of the component is to use the width and height attributes, preferably with the style. <jvf:view width="500" height="500" /> The view component is the central component of a JViews Framework Faces application. All the other components depend or interact on this view, which can be extended to make more specific components. Manager View The view component is designed to show the content of a manager view. You can connect a manager view to a view component by using a binding: <jvf:view [...] view="#{frameworkbean.managerview" /> The manager view to be displayed will be retrieved in a Bean, called the frameworkbean, and declared in the JavaServer Faces environment. This Bean should then provide the manager view through its getmanagerview method: public class FrameworkBean { private IlvManagerView managerview; [...] public FrameworkBean() { [...] initmanagerview(); protected void initmanagerview() { [...] public IlvManagerView getmanagerview() { return managerview; public void setmanagerview(ilvmanagerview managerview) { - 18 / 23 -

this.managerview = managerview; To use the value binding attribute, the Bean must be declared in the facesconfig.xml file or the managed-beans.xml: <faces-config> <managed-bean> <description>a demo bean</description> <managed-bean-name>frameworkbean</managed-bean-name> <managed-bean-class>frameworkbean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> </faces-config> Installing Interactors You can now install interactors on the view: <jvf:zoominteractor id="zoom" /> <jvf:view interactorid="zoom" [...] /> The link between the view and the zoom interactor is made through the identifier of the interactor. It is now possible to zoom in on an area in the view using a rectangle dragged across the view. Adding an Overview An overview displays the global area and a rectangle corresponding to the area visible in the main view. You can move this rectangle to change the area visible in the main view. This overview is connected with the view in the usual way with the identifier. <jvf:view id="view" [...] /> - 19 / 23 -

<jvf:overview viewid="view" [...] /> Adding a Pan Tool and a Zoom Tool The zoomtool component shows a set of buttons. Each button corresponds to a zoom level. Clicking a button will set the view to the corresponding zoom level. The button corresponding to the current zoom level is displayed differently from the other buttons so that you can tell which zoom level is being used. The component can be vertical or horizontal. The pantool component is a component that allows you to pan the view in all directions. The connection to the view is made by setting the identifier of the view to the viewid property of the tools. <jvf:view id="view" [...] /> <jvf:pantool viewid="view" [...] /> <jvf:zoomtool viewid="view" [...] /> Improving the Pages After defining the global look and feel of the pages, it is possible to improve the results with additional JavaScript code, advanced interactors and custom code. Once again, particular attention should be given to minimizing the number of refreshes to avoid a page submit. Diagram displays using JSF - 20 / 23 -

Charts and Gantt Displays In the ILOG JViews product line, the same development approach has been generalized to other modules. The ILOG JViews Charts and Gantt products come with JSF components that have been designed to help developers quickly add generic interactive Web components. Their architecture and the way they can be included in the development cycle are consistent with the approach suggested in this paper. Chart Displays using JSF JSF-based Gantt charts and GIS maps - 21 / 23 -

Conclusion In this paper, we have shown you how to write a simple JSF component. Doing so is easy because the JSF framework does most of the work by managing the component state, the renderers and other properties. We then extended these basic concepts to design an advanced graphical JSF component able to display complex data sets, offer incremental refresh, support rich client-side interactions and coordinate with companion components. This required many enhancements to the basic JSF component architecture to support these features. As shown, incremental refresh would be a good future enhancement to the JSF framework. It allows only certain parts of page to have to be rerendered, avoiding a complete refresh of the page. Our example shows that following the JSF specifications is not always enough to ensure a component can be fully integrated into a JSF IDE and that a new JSR should solve this problem soon. Despite these pitfalls, the JSF framework greatly speeds up Web component development and facilitates mixing components from various sources to build complete and complex Web applications. To minimize the amount of work needed to create specialized graphical components, the ILOG JViews product line offers off-the-shelf JSF components that can be quickly and easily added to JSF applications. The most notable benefits for developers: Ease of development: Ready-to-use JSF components and tags make it easy to build sophisticated Web pages with same complexity as regular JSP pages. Also, JavaScript coding is no longer required for simple behaviors. With the wide availability of JSF-enabled IDEs, development of visually rich pages is as simple as JavaBean development for thick clients. Ease of integration: With new JSF features for navigation, localization and events, and interactive graphical components consistent with other JSP components, integration is seamless and much simpler. Reusable components: A clear separation of visual parameters, application logic and image providers enables components to be well designed, more generic and easily reused. Leverage ILOG s experience: As an early adopter and active promoter of JSF, ILOG has acquired an advanced knowledge of this technology that we offer through ILOG JViews to enable developers to immediately take advantage of this technology. - 22 / 23 -

References 1. JSR 127: JavaServer Faces http://jcp.org/en/jsr/detail?id=127 2. Developing Advanced Graphics Components Using JavaServer Faces Technology http://www.javaone04.com/session-html/ts-1936.html 3. Creating Custom UI Components http://java.sun.com/j2ee/1.4/docs/tutorial/doc/jsfcustom.html 4. JSR 168: Portlet Specification http://jcp.org/en/jsr/detail?id=168 5. Sun Java Studio Creator http://developers.sun.com/prodtech/javatools/jscreator/index.jsp 6. Rational Application Developer for WebSphere Software http://www- 306.ibm.com/software/awdtools/developer/application/index.html Further reading For a more complete description of how to build a JSF application, please see the article posted by Sun Microsystems at http://java.sun.com/developer/technicalarticles/gui/javaserverfaces. - 23 / 23 -