如今，许多Web应用程序开发人员都在转而使用JSF，但是他们发现，预先定制的JSF UI组件受到基本DHTML窗口部件的限制。监管或业务流程监控之类的高级应用程序需要能与JSF框架兼容的高级可视化组件。JSF框架的标准化使它易于开发能够重用的自定义Web GUI组件。另外，Web组件开发商现在能提供更复杂的组件，并承诺Web应用程序开发人员能够轻松地使用这些组件。此类JSF用户界面组件必须集成并部署到JSF运行时框架中去，并在其中完全展开，还必须在设计时很好地集成到提供JSF支持的IDE中去。

　　尽管JSF带来了标准用户界面框架，但对于开发第一个自定义JSF组件而言，还是存在几个缺陷和漏洞。让我们看看怎样创建一个纯HTML无法轻松创建的图形JSF组件。图形JSF组件的特点不仅要求生成DHTML，而且还需要对图像生成和客户端交互提供补充支持。我们将以一个图形组件的例子来阐述这些特点。该图形组件能够提供曲线图，并为各种客户端导航和交互提供便利。我们还会了解到将该图形组件集成到JSF-enabled IDE中所需要的步骤。通过理解图形组件的设计方法，您将会更好地理解如何实现JSF组件，而这应该能使您开发出定制的JSF图形组件。

什么是JSF？

　　JSF是一种能够简化Web应用程序表示层结构的标准服务器端框架。定义JSF框架的JSR 127（参见参考资料）带有一个能提供基本UI组件（如输入栏和按纽）的参考实现。您可以将可重用用户界面组件集中起来创建Web页，将这些组件绑定到应用数据源上，并用服务器端事件控制程序处理客户端事件。根据说明书介绍，组件供应商能编写与JSF运行时框架集成的组件，并将其集成到在设计时与JSF兼容的IDE中去。

　　从很大程度上讲，JSF组件同在HTML 2.0技术要求下可用的HTML组件和标签直接相符合。对许多Web应用程序而言，这套相对简单的组件是够用的。然而，许多应用程序如监管或监控程序需要更复杂的数据显示与交互，比如制表、制图和映射。由于JSF组件在HTML中直接提交复杂图形小部件的能力有限，所以设计这些高级组件的能力并不突出。解决方案要求服务器端组件向客户传输图像，却会给自身带来问题，因为在基本HTML图像上进行交互要受到限制。最后，使用JavaScript时，必须能调用客户端交互来使用户能对数据进行导航和交互。

　　让我们看看开发一个简单的、将CSS输入HTML页面的JSF组件需要哪些步骤。当开发高级JSF图形组件时，这一简单组件的描述和代码样本会作为背景。图1显示了如何使用即将开发的组件，并显示将要得到的结果。使用这种组件的好处是能够通过改变某个JSF动作的组件值，来改变整个页面的外观。

图1：显示了我们如何使用一个非常简单的JSF组件将CSS输入某个HTML页面并得出结果。

开发组件

　　JSF组件包含若干个Java类和配置文件。为创建一个自定义JSF组件，您需要开发一个扩展JSF基本组件类的Java类；为默认呈现软件包开发呈现程序；开发一个将在JSP页面中用于描述标签的Java类；编写一个标签库定义（TLD）文件；编写JSF配置文件。让我们更深入地了解这5个步骤。

　　开发组件Java类。组件类负责管理代表组件状态的属性。因此，我们必须根据组件的行为（如输入组件或输出组件），给组件选择适当的基类（参见清单1）。这里描述的组件可进行扩展javax.faces.component.UIOutput，以显示指向某个样式表文件的URL，或内联式样式表的内容。该组件可用于在JSF动作中将某个样式表转换成另一个样式表。关联属性规定着值的类型：要么是一个URL，要么是内联样式。该组件还必须能够在向服务器发送请求期间，使用经过JSF框架处理的对象，来存储并修复自己的状态。组件的状态由重建对象所需的重要属性值组成。JSF框架自动调用saveState()和restoreState()方法，我们可以在组件中实现这两种方法来达到这一目标。

清单1. 组件类管理显示组件状态的属性。可依据组件的行为，为其选择一个适当的基类。在本例中，该组件扩展javax.faces.component.UIOutput，以显示指向某个样式表文件的URL，或者某个内联式样式表的内容。

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]; 
	} 
}

开发呈现程序。呈现程序有两个作用。第一，呈现程序负责发送适当的HTML程序段，该程序段能在客户端中呈现组件。通常情况下，这个HTML程序段由一些适于呈现整个Web浏览器的HTML标签组成。此JSF生存周期称作编码阶段或呈现—响应阶段。该响应阶段还能发送增强客户端交互性的JavaScript代码。

　　呈现程序的第二个作用是解析来自客户端的数据，从而对服务器端的组件状态进行更新（如用户在文本字段输入的文本）。标准呈现程序软件包具有强制性，但也可以提供其他呈现程序软件包，用于提供可替换的客户端表示法或SVG之类的语言（参见参考资料）。通过检验组件的连接属性，您实现的呈现程序（参见清单2）将选择在HTML页面中发送的CSS样式。

清单2. 标准呈现程序软件包具有强制性，但是，您可以使用其他呈现程序软件包，来提供可替换的客户端表示法或语言。通过检验组件的连接属性，您实现的呈现程序将选择在HTML页面中发出的CSS样式。

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"); 
		}
	}
}

开发标签类。同样，JSF框架提供了用于扩展的基类，来编写与组件相关的标签。该标签类负责定义并呈现将在faces-config.xml文件中应用的组件样式（这种样式的描述很简短）。它还负责创建JSF组件（由JSF框架来处理），传递JSF标签中所包含的属性，该属性用于初始化组件（参见清单3）。

清单3. 该标签类定义了将在faces-config.xml文件中应用的组件的样式和组件呈现方式。

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;
	}
}

　　该标签提供setter和getter来管理链接和值属性。组件一旦创建，便会调用setProperties()方法，对标签属性进行初始化。每个标签属性都无外乎两种：要么是文字值，要么是bean属性的一个绑定。

编写标签库定义（TLD）。TLD是一个XML文件，它通过将标签名与相应的Java类相关联来描述标签。TLD还描述了标签所允许的属性（参见清单4）。这个TLD定义了一个名为css的标签，该标签绑定到CSSTag类。它还声明了链接和值标签属性。

清单4. TLD是一个通过将标签名与相应的Java类相关联来描述标签的XML文件。TLD定义了名为css的标签，使其与CSSTag类绑定。它还声明了链接和值标签属性。

<?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/web-jsptaglibrary_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>

编写JSF配置文件。为了将某个JSF组件集成到框架中，您必须提供一个名为faces-config.xml的配置文件。该文件将组件类型和呈现程序类型（用于JSP定制标签处理程序）与对应的Java类关联起来。它还能描述与每个组件一同使用的呈现程序（参见清单5）。该文件定义了faces.CSSFamily组件家族。在本例中，该家族由faces.CSSComponent这一个组件类型（该类型与CSSComponent类绑定）组成。最后，HTML.LinkOrInlineRenderer类型的呈现程序（由CSSComponent类实现）要与faces.CSSFamily家族相关联。

<!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>

开始制图

　　如果您希望将自己的组件集成到JSF-enabled IDE中，您还可以提供补充说明。比如说，除提供其他的设计时信息外，还可以提供一个名为sun-faces-config.xml的XML配置文件，用于描述应在IDE中公开的组件属性。

　　既然已经看到如何创建一个简单的JSF组件，不妨再来看看怎样创建一个图形JSF组件。我们将遵循同样的基本步骤来设计一个高级JSF图形组件。让我们以一个图形组件（如ILOG JSF图形组件）为例，通过一组分类，该组件为数据值分布提供了可视化表示。该图形能够以条型统计图、圆形分格统计图和气泡式统计图等各种显示方法来显示数据集合。该JSF图形组件有两个初始设计限制：

　　我们已经拥有Java图形bean组件，它具备所有图形显示能力。该组件可以显示很多图形，而且可定制性很高。在理想情况下，我们希望利用bean组件，使用它的功能来构成我们的JSF组件的基础。

　　普通JSF应用程序需要重新载入整个页面以更新视图。这种方法适合基于表单的应用程序，但在很多情况下却不适用于高度图形化的用户界面。因此，我们的JSF图形组件必须能在不更新整个页面的前提下处理某些简单的导航，以提供更好的用户体验。

　　以下是满足这些需求的解决方案：该JSF图形组件将管理图形bean组件，包括创建图形bean、定制该bean以及使该bean可用于服务器端操作。呈现JSF组件将分为两个阶段完成。JSF呈现程序会产生一个<img>标签和一套JavaScript对象（参见图2）。客户端将请求服务器发回一张图像。这一请求由某个servlet完成，该servlet获得图形bean，并利用图形提供的方法生成一幅图像（参见图3）。任何只改变该图形外观的进一步用户交互（放大、扫视、更改样式表等）都会引起图形的一次增量更新。如果客户端不只是要求对图形图像进行更新，那么将提交该页面（参见图4）。

　　图2JSF图形组件管理图形bean组件，包括创建图形bean、对其进行定制，并使其可用于服务器端动作。JSF呈现程序生成一个<img>标签和一套JavaScript对象。

　　图3 客户机通过servlet要求服务器获得一张图像。该servlet获得图形bean，并通过由图形提供的方法生成一幅图像。

　　图4如果客户端不只是要求对图形外观的进行更新，那么页面将被提交。

　　JSF图形组件还配有一套附加的JSF组件。overview可显示该图形整体视图，显示一个代表图形视图的长方形，还应允许用户扫描可视区域。legend组件可显示数据集合的相关信息，还能自行在图形中显示，依被显示数据的样式而定。也能提供客户端的interactors如扫描和放大，这些功能可看成是客户端交互，表示与图形的交互不会像一次正常的JSF交互那样重新载入整个页面。

　　要想呈现图形组件，只需使用chartView标签：

<jvcf:chartView id="c" style="width:500px;height:300px" … />

　　该数据在HTML页面中作为图像显示。该图像由servlet创建，旨在响应一次HTTP请求（该请求包括指定结果图像、生成图像映射以及生成内联式图例等各种参数）。结果图像随之被嵌入客户端DOM，页面中只有图像自身这一部分被更新。

应用程序核心部件

　　让我们看看简单的定制JSF组件和高级图形组件之间的一些区别。JSF图形组件类很像一个标准组件，不过是多了一个可访问图形bean（该图形bean负责生成在HTML页面中显示的图像）的图形属性。JSF组件可以通过某个绑定值或在当前会话中对这个图形bean进行局部检索。当JSF图形组件成为某个应用程序的核心部件时，可选的JSF组件（如概览或图例）便与主图形相关联，来显示附加信息（见清单6）。

清单6. 当JSF图形组件成为某个应用程序的核心部件时，可选的JSF组件便与主图形相关联，来显示附加信息。

<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" />

　　呈现程序是实现这个JSF的一大难点。如前所述，呈现程序并不生成简单的HTML，而是生成由HTML（<IMG> tag）和JavaScript proxy（代理程序）组成的动态HTML（DHTML）。

　　Proxy是一个负责管理客户机组件图像显示的JavaScript类实例。该对象是服务器端Java组件类在客户端显示；它与组件类具有相同属性。页面上的每个组件、图形及其配件都有一个proxy实例。呈现JavaScript时，在每个可视的JavaScript变量上使用facesContext.getExternalContext().encodeNamespace(name)方法是个很好的实践。这样做在今后方便地将组件集成到到JSR 168-compliant端口环境中。

　　为举例说明客户机上的proxy，必须在页面上导入JavaScript支持库。为保持客户端尽量瘦，需要基于JavaScript库支持的proxy类，对JavaScript库进行模块化。因此，需要给每个proxy类输入一套不同的、有可能重叠的库。图形呈现的困难部分，出现在发送这些script库的阶段。每个组件的呈现程序都要声明自己需要哪个库，以及什么时候发送引用的库，必须认清已发送的库，以避免重复。仅在页面呈现期间的存在script管理器负责这项筛选工作。每当呈现程序想要发送整套库输入时，它都会向筛选出已发送库的script管理器提供列表。

　　客户端proxy的目的在于允许编写脚本，并避免不必要的页面更新。一旦呈现了图形，在客户端便可使用proxy，以便动态安装interactor，并显示或隐藏图像映射。Proxy对象也可供支持JavaScript鼠标事件处理的常规JSF组件使用。

<jvcf:chartView id=
	"chartView" .. />
<h:selectBooleanCheckbox id=
	"genImageMap" onclick=
	"chartView.setGenerateImageMap(
	this.checked ? true : false, 
 true);" />

　　对组件客户端proxy进行局部修改的问题在于，其状态不再与服务器上的Java组件的状态同步。为解决这个问题，proxy使用一个隐藏的输入标签（<INPUT TYPE="HIDDEN">）来保存客户机上的新状态。当执行某个标准JSF动作并提交页面时，呈现程序将解析该隐藏状态，使客户机与服务器同步。这种行为需要呈现程序类中有专门的破解行为。标准破解方法得以改进，以便解析来自客户机的状态，并更新服务器端组件的状态。

测试实例

　　图形及其相关组件之间的关联由标记引用与绑定来完成。为使页面设计具有灵活性，一个组件可以在呈现之前被引用。因此，在呈现时间内，如果某个组件属性引用另一个尚未呈现的组件，那么，将延迟发送依赖于客户机进行解决的JavaScript代码，直到呈现已引用的组件。此工作可由依赖性管理器完成。

为证实这一点，不妨看一个典型实例，该实例涉及某个概览，该概览引用一张图形。

<jvcf:overview viewId=
	"chart" [...] /> 
<jvcf:chartView id=
	"chart" [....] />

　　存在两种情况。被引用图形组件已经呈现，因此不存在任何问题

JSP:
<jvcf:chartView id=
	"chart" [....] />
<jvcf:overview viewId=
	"chart" id="overview" [...] /> 

render:
[...]
var chart = 
	new IlvChartViewProxy ( .. );
[...]

var overview= 
	new IlvFacesOverviewProxy (
	 .. );
overview.setView(chart);
[...]

　　已引用图形的组件在依赖的概览组件之前不会呈现。既然如此，可在依赖性管理器上注册一个组件创建监视器。已引用图形组件最终呈现时，其呈现程序会通知自己创建的依赖性管理器。此时，将发送解决依赖性所需的代码：

JSP:
<jvf:overview viewId=
	"chart" id="overview" [...] /> 
<jvdf:chartView id=
	"chart" [....] />

render:
[...]
var overview = 
	new IlvFacesOverviewProxy (
	 .. );
[...]

var chart = 
	new IlvChartViewProxy ( .. );
overview.setView(chart);
[...]

　　开发JSF组件的目的之一，是能够将它们应用于任何与JSF兼容的IDE。尽管如此，JSF兼容性并不足以保证这种设计时集成将会有效。下面是在开发JSF组件过程中，为了便于在今后与IDE集成需要注意的一些简单思想：

　　首先，定制JSF组件应该提供一个基本HTML呈现程序。在设计时，JSF IDE不能呈现请求有效数据或app服务器连接的动态图形组件。因此，带有复杂的或非传统的（比如不是HTML）呈现程序的组件，应该使用Beans.isDesignTime()来确定是提供一个基本HTML表示法，还是提供真正的组件呈现程序。

　　另一个设计时问题是组件的位置和大小。不同IDE使用不同的标志和属性。能够调整大小的组件（如一幅图像）应能处理定义大小的不同方式。

　　最后，为了与IDE集成，组件必须提供尚未被JSF说明定义的补充信息。遗憾的是，当前每个IDE都需要特殊处理程序来集成组件，即：在一种情况就需要XML文件，而在另一种情况下需要eclipse插件，如此等等。下一个JSF JSR（2.0版）的主要目的之一，将是指定附加的元数据格式。

　　如您所见，编写一个简单的JSF组件并不难，因为框架已经完成了大部分工作。JSF框架管理着组件状态、呈现程序等等。在本文中，我们已经扩展了这些基本概念，来设计一个能够显示复杂元数据、提供增量更新、支持大量客户端交互并与配套组件协作的高级图形JSF组件。支持这些特点需要对基本JSF组件的结构进行许多改进。当然，增量更新的概念今后对JSF框架将是一个很好的完善，因为它只允许呈现页面已改变的部分，避免了更新整个页面。按照JSF说明书工作往往不足以确保组件完全集成到JSF IDE中；一个新JSR应能及时解决这些难题。尽管存在缺陷，JSF框架仍能极大地加快Web组件开发速度、方便的融合来自各种资源的组件，以创建完整的、复杂的Web应用程序。

参考资料

• developer.sun.com
  Java 工具
  Sun Java Studio Creator
  Developing Web Applications with JavaServer Faces
• IBM
  Rational 软件
  Rational Application Developer for WebSphere Software
• Java Community Process
  Java Specification Requests JSR 127: JavaServer Faces
  JSR 168: Portlet Specification

作者简介

　　Marc Durocher是ILOG的一名软件架构师，ILOG是企业级软件组件和服务的主要提供商。Marc Durocher在ILOG负责开发ILOG JViews生产线上的JSF组件。可以通过mdurocher@ilog.fr联系Marc。

原文出处

http://www.ftponline.com/weblogicpro/2005_03/magazine/features/mdurocher/

Problem Description

The Java 2 Enterprise Edition includes JavaServer Faces technology, which provides a mature and extensible user interface component model. The design of this model makes it easy for application developers to create custom components by extending the standard components included with JavaServer Faces technology and to reuse these components across applications.

The example featured in this entry includes a JavaServer Faces text field component that takes the name of a city.  When the user begins entering characters in the field, the application uses AJAX to perform auto completion on the data by matching the user's input to a list of cities stored on the server.  In two of the versions of this example, the text field component is a custom JavaServer Faces component that provides the AJAX support.  This component shields the page author from the complexities of AJAX by rendering all the HTML and JavaScript code that is required to incorporate AJAX capabilities into an application.

A third version of this example adds AJAX support to a standard JavaServer Faces component through a servlet that interacts with the JavaServer Faces component and other JavaServer Faces server-side objects to generate the appropriate auto completion data.

This entry focuses primarily on the question, "How can I incorporate AJAX functionality into a JavaServer Faces application?"

Among the other questions that this entry considers are the following:

• Should AJAX request handling be done in a separate servlet controller or should it be handled by the JavaServer Faces technology life cycle?
• How can existing components be AJAX-enabled without rewriting them?
• Should JavaScript code be embedded in Java code or externalized in a separate script file?
• How does the programming model differ between component writer and page developer?
• How should I organize the project structure in my workspace?
  
• How should I package the JavaServer Faces objects and JavaScript artifacts into a WAR file or EAR file?
  

Solution

Developers who want to include AJAX support in JavaServer Faces applications have more than one strategy to choose from.  Which strategy they choose depends on the needs of their situation.  Developers might ask themselves the following questions to help them decide which strategy to select:

• Is this a new application or is the development team adding AJAX support to an existing JavaServer Faces application?
• Is the page author capable of adding the JavaScript and AJAX code to the page, or should it be handled by a server-side component so that the page author can simply add the component tag to the page?
• Must the AJAX code be reusable?
• Must the AJAX code be customizable?
• Must the AJAX code be usable outside of the JavaServer Faces technology runtime?
  
• Is the application developer capable of doing the extra programming required to synchronize data with the JavaServer Faces objects if the development team decides to de-couple the AJAX code from the JavaServer Faces runtime?

This entry discusses three strategies for incorporating AJAX support into a JavaServer Faces application.  The first two strategies involve creating a custom component to generate the necessary JavaScript and to make AJAX interactions with another server-side component.  In Strategy 1, the JavaServer Faces technology life cycle and the custom component handle the AJAX requests.  In Strategy 2, the custom component communicates with a special servlet, which handles all the AJAX requests.  Strategy 3 does not require any custom components; all the additional AJAX support is performed by a servlet provided by the developer.

Strategy 1 and Strategy 2 require knowledge of the JavaServer Faces technolgy life cycle to implement them. Strategy 3 requires knowledge of the Java servlet API.

The following sections explain the three strategies and provide more detail on their advantages and disadvantages.   After reading about these strategies and answering the list of questions above, developers should be able to select the strategy that is appropriate for their particular situation.  The Comparison of Strategies section includes a chart that summarizes the characteristics of each strategy, which makes it even easier to make the decision.

Strategy 1: A Custom JavaServer Faces Component Renders Client-side AJAX JavaScript and Processes AJAX Requests

In this strategy the JavaServer Faces component does three things:


• Renders the HTML for the form elements
• Renders the links to the JavaScript code that handles the form events
• Processes AJAX requests

Figure 1: Architecture of a JavaServer Faces Component that Renders Client-Side AJAX JavaScript and Processes AJAX Requests

The following steps explain the architecture illustrated in Figure 1:


1. The page called Enter Address Page contains an HTML script element rendered by the renderer,  AutoCompleteTextRenderer.
2. A call is made to the URL, faces/autocomplete-script, which is mapped to a FacesServlet instance.  This instance processes the RenderPhaseListener instance, which recognizes the URI and returns the component.js page containing the client-side JavaScript code necessary for the AJAX interactions. After the component.js page is returned, the RenderPhaseListener instance stops taking part in the JavaServer Faces technology life cycle processing for now.
3. When the user starts typing in the City text field, an onkeypress event occurs. The JavaScript function mapped to this event creates an XMLHttpRequest object and configures it with the URL to the FacesServlet instance. This URL is faces/autocomplete&id=San. The id=San part of the URL is a URL parameter in which San is the user input that is matched against the list of cities. The XMLHttpRequest object makes a call to the FacesServlet instance. HTML page events continue to be processed by the JSP page.
   
4. The FacesServlet instance processes the RenderPhaseListener instance that recognizes the URL faces/autocomplete and looks up the AutoCompleteTextField component, which provides the completion logic.
5. The RenderPhaseListener instance generates an XML document containing the potential completion items and returns it to the XMLHttpRequest object, which then calls the XMLHttpRequest callback function.
6. The XMLHttpRequest callback function updates the HTML DOM based on the contents of the XML document that was returned.
7. After entering the form data, the user clicks the Update button and the form is posted using an HTTP POST to the FacesServlet instance, which updates SessionBean with the address information entered by the user.
   

The remainder of this section provides further details on how this strategy works.

In Figure 1, the page called Enter Address Page is a JavaServer Faces page. This page contains a tag that represents the AutocompleteTextField component, which is a JavaServer Faces component.  This component renders two things: an HTML text field, into which the user enters the name of a city, and the necessary client-side JavaScript AJAX code that fetches possible city names from a server-side managed bean.  This managed bean contains a method that implements the algorithm for completing city names.

To add the AJAX-enabled component to the application, the page author need only include the following tag in the page:

 <ajaxTags:completionField size="40" id="cityField" 
 completionMethod="#{AutoCompleteTextfield.completeCity}" 
 value="#{SessionBean.city}" required="true"
 />

Code Example 1: Declaring an AJAX-enabled JavaServer Faces Component in a JavaServer Faces  page

The AutoCompleteTextFieldTag tag handler implements the ajaxTags:completionField tag, which is rendered to HTML by the renderer, AutoCompleteTextFieldRenderer. The first time the component is encountered in the page, AutoCompleteTextFieldRenderer renders a reference to external JavaScript code, as shown in this HTML fragment:

 <script type="text/javascript" src="faces/autocomplete-script">

Code Example 2: Rendered HTML that references JavaScript to be returned by RenderPhaseListener

When the reference to the external script file is reached, the browser makes a request to the URL, faces/autocomplete-script. The request first goes to the FacesServlet instance and is then received by the RenderPhaseListener instance, which returns the client-side JavaScript relevant to the AJAX interactions of the component. In the case of this example, the component.js file is included with the component and returned using the class loader. Bundling the relevant JavaScript code with the component is a good practice because it keeps the script and component close to each other but keeps the JavaScript out of the component code. The AJAX client-side JavaScript contains the XMLHttpRequest callback method, which includes the event mappings to the form elements rendered by AutoCompleteTextFieldRenderer.

When the target onkeypress event is encountered in the City form field, the client-side XMLHttpRequest object makes a HTTP GET call with the partial text input from the field to the FacesServlet instance, which in turn calls the RenderPhaseListener instance.  The RenderPhaseListener instance looks up the AutoCompleteTextField component and gets a set of city names that match partial text input. For example, if the user entered "San" into the field, the component would fetch the set of city names that start with the string "San".


At this point, the RenderPhaseListener instance can access the view state associated with the page if it is needed to process the interaction.  When processing AJAX requests with JavaServer Faces components, a developer can treat each AJAX request as a new request by using simple HTTP GET calls.  In this case, every request is a new Faces request.  Or the developer can use POST calls, which give access to the view state associated with the JavaServer Faces page. Strategy 1A provides further details on using POST calls to access view state.  When using AJAX GET requests with JavaServer Faces technology, a developer has access to managed bean components and has the ability to evaluate expressions but does not have access to the view state.

In the case of this example, each auto complete AJAX request is a GET request and is therefore a new Faces request. The RenderPhaseListener instance renders an XML response based on the results obtained from the AutoCompleteTextField component.

The server-side AJAX request processing is provided by a RenderPhaseListener instance.  From the perspective of a server-side developer, the requests are a little different from other AJAX requests in that they usually do not go through all the phases of the JavaServer Faces technology life cycle. The following code shows how the RenderPhaseListener instance handles an AJAX request:

    private void handleAjaxRequest(PhaseEvent event) {
       FacesContext context = event.getFacesContext();
       HttpServletResponse response =
            (HttpServletResponse)context.getExternalContext().getResponse();
        ..
        if ("complete".equals(action)) {
            String method = request.getParameter("method");
            try {
                //get completion items
                response.setContentType("text/xml");
                response.setHeader("Cache-Control", "no-cache");
                //Code to write XML response goes here...

                event.getFacesContext().responseComplete();
                return;
            } catch (EvaluationException ee) {
                ee.printStackTrace();
            } catch (IOException ioe) {
                ioe.printStackTrace();
            }
        }
    }
  

Code Example 3: PhaseListener code to handle AJAX requests

One thing the developer needs to remember is that the content type must be set to "text/xml" and the Cache-Control header also needs to be set to "no-cache" as shown in the following code snippet, which is taken from Code Example 3.

 response.setContentType("text/xml");
 response.setHeader("Cache-Control", "no-cache");

The call to event.getFacesContext().responseComplete() following the creation of the XML response causes the rest of the JavaServer Faces life cycle to be skipped.

The response is returned to the XMLHttpRequest callback method, which updates the HTML DOM with the list of potential city names.

The end user might then select a relevant city name from the list returned from the AutoCompleteTextField component and click on the Update button, which causes the form to be submitted to the FacesServlet instance, after which the SessionBean object is updated.

This strategy makes it easy for page authors to add AJAX-enabled components to a JavaServer Faces page.  As long as the component is added to the application, all they need to do is include the corresponding component tag in the page.


The component developer can make the component more customizable by allowing external JavaScript files to override the embedded file as well as allowing the use of external style sheets.  One way to do this is to include JavaScript and CSS properties on the component that the user can override. For example, the AutocompletionTextField component can have an ondisplay property that lets users of the component specify JavaScript code that is executed when an item is selected from the popup. Similarly, a selectedItemStyle property could let the user specify a CSS or a CSS style class to be applied to selected items in the popup.

Strategy 1A: Doing AJAX processing against the full View

This approach is used by the AJAX Progress Bar for JavaServer Faces Technology. As with Strategy 1, FacesServlet is used to orchestrate all the processing of AJAX requests and all the serving of script files. The main difference between Strategy 1 and Strategy 1A is the use of POST to submit the actual view state back to the server. Doing this requires the AJAX-enabled components to abort normal page processing to prevent rendering of the entire JSP page for AJAX requests. This is done the same way as in Strategy 1, using the responseComplete method on the FacesContext instance. Another difference in the architecture of the progress bar example is that the PhaseListener instance is responsible only for rendering the script, whereas ProgressBarRenderer writes out the response XML that is handled by the AJAX JavaScript code.

Another complexity resulting from the polling nature of the progress bar is the need for a closure to the function passed to the setTimeout JavaScript method. The progress bar uses the technique described by Richard Cornford at http://jibbering.com/faq/faq_notes/closures.html. This is a very handy technique when coding AJAX-enabled components.

Performance should be considered when determining how much view state is associated with each request relative to the volume of AJAX requests being processed when using this approach. While this approach is more tightly coupled with the JavaServer Faces life cycle and therefore provides ready access to Faces objects, this tight coupling could result in a performance degradation compared to the strategy of using a separate AJAX controller, which would not have a tight coupling to the view state.

Strategy 2: A Custom JavaServer Faces Component with Separate AJAX Controller

In this strategy the JavaScript rendered by the JavaServer Faces component communicates with a separate servlet. All asynchronous requests will therefore be handled outside of the JavaServer Faces technology life cycle processing. However, the separate servlet can look up the FacesContext instance and evaluate value binding and method binding expressions so that it can do such things as find managed beans and make calls to them.


Figure 2 illustrates this strategy.  The numbered steps following the figure explain what is happening in the figure.



Figure 2: Architecture of a JavaServer Faces Component with separate AJAX Controller

The following list describes the interactions shown in Figure 2:


1. The page, called Enter Address Page, contains an HTML script element that is rendered by the renderer,  AutoCompleteTextRenderer.
2. A call is made to the URL, faces/autocomplete-script, which is mapped to the FacesServlet instance. This instance processes the RenderPhaseListener instance, which recognizes the URL and returns the component.js page containing the client-side JavaScript code necessary for the AJAX interactions. After the component.js page is returned, the RenderPhaseListener instance stops contributing to the JavaServer Faces technology life cycle processing for now.
3. When the user enters text into the City text field, an onkeypress event is generated. The JavaScript function mapped to this event creates an XMLHttpRequest object and configures it with the URL to the AjaxControllerServlet instance. This URL is autocomplete&id=San. The id=San part of the URL is a URL parameter in which San is the user input that is matched against the list of cities.
   
4. The XMLHttpRequest object makes the call to the AjaxControllerServlet instance, and HTML page events continue to be processed by the page.  The AjaxControllerServlet instance looks up the AutoCompleteTextField component and gets a list of potential completion items.
5. The AjaxControllerServlet instance generates an XML document containing the potential completion items and returns it to the XMLHttpRequest object. The XMLHttpRequest object then calls the XMLHttpRequest callback function.
6. The XMLHttpRequest callback function updates the HTML DOM with the list of city names, which are contained in the returned XML document.  At this point, users can select a city name, and when they do, the form element's value is set with the selected value.
   
7. After entering the form data, the user clicks the Update button and the form is POSTed to the FacesServlet instance, which updates the SessionBean object with the address information entered by the user.

This strategy provides a clean separation of the AJAX interaction logic and the traffic that is usually handled by the FacesServlet instance. Each AJAX request is a new request that the JavaServer Faces technology life cycle does not see, meaning that AjaxControllerServlet does not have access to the JavaServer Faces page view state. The AJAX servlet can communicate with the managed beans and evaluate expressions by looking up the FacesContext instance and calling the corresponding code.

The strategy is similar to Strategy 1 in that all "plumbing" is generated by the JavaServer Faces component itself. In this strategy, the JavaServer Faces component is depending on a separate dedicated servlet to handle the JavaScript events it is adding to the rendered HTML. Updates to the JavaServer Faces model data occur outside the scope of the JavaServer Faces technology life cycle request/response processing, and so care should be taken that model data is consistent.

Strategy 3: Retrofitting an Existing JavaServer Faces Application

In this strategy, no custom JavaServer Faces components are used. As in Strategy 2, a separate dedicated AJAX servlet is used, and custom JavaScript code is added to the JSP page for the purpose of communicating with the servlet. Developers are responsible for all the "plumbing".  This means that they must provide the code that handles JavaScript events associated with the JavaServer Faces components, makes asynchronous calls, and updates the HTML document when responses arrive.


Figure 3 illustrates this strategy.  The numbered steps following the figure explain what is happening in the figure.



Figure 3: Retrofitting an Existing JavaServer Faces Application

The following steps explain the architecture of the JavaServer Faces application shown in Figure 3:

1. The page, called Enter Address Page, contains the client-side JavaScript code necessary for the AJAX interactions.
2. When the user types in the City text field, an onkeypress event is generated. The JavaScript function mapped to this event creates an XMLHttpRequest object and configures it as a URL to the AjaxControllerServlet instance. This URL is autocomplete&id=San. The id=San part of the URL is a URL parameter in which San is the user input that is matched against the list of cities. After the XMLHttpRequest object makes the call to AjaxControllerServlet, the page continues to process HTML page events.
3. AjaxControllerServlet looks up the CitiesBean managed bean and gets a list of potential completion items.
4. The AjaxControllerServlet instance generates an XML document containing the potential completion items and returns it to the XMLHttpRequest object. The XMLHttpRequest object calls the XMLHttpRequest callback function.
5. The XMLHttpRequest callback function updates the HTML DOM based on the contents of the XML document that was returned.
6. After entering the form data, the user clicks the Update button and the form is POSTed to the FacesServlet instance, which updates the SessionBean object with the respective address information.

Figure 3 is very similar to Figure 2, which illustrates Strategy 2, with one exception: In Strategy 2, the servlet is provided with the JavaServer Faces component and handles "generic" traffic. In Strategy 3, the JavaScript and the servlet are provided by the application developer.  Notice that the servlet talks about the application-specific list of cities, whereas in Strategy 2 the servlet handles generic items.  This is because strategy 2 is designed to be reusable in that the solution can be utilitzed to handle various auto completion use cases, such as completing city names, state names, or people names, whereas Strategy 3 is bound to the specific use case of completing city names.


This strategy has the advantage of not relying on any special AJAX-enabled JavaServer Faces components, and therefore,  any existing JavaServer Faces application can be retrofitted with custom JavaScript and a special servlet to handle AJAX behavior. However, like Strategy 2, the use of a separate servlet makes calling JavaServer Faces methods more difficult.  Furthermore, it is impossible to get access to the view state of the JavaServer Faces page.

This strategy allows for more customization of the JavaScript code that provides the AJAX interaction, but it is also more difficult to maintain and requires that the page author be familiar with AJAX interactions and JavaScript. The page author is responsible for matching the events generated by the HTML elements to the JavaScript functions. Doing this might be difficult for the average page author because the HTML elements are generated by a JavaServer Faces component renderer, and therefore the page author must be somewhat familiar with the server-side renderer code.  In addition, the page author is also responsible for making sure that the AJAX updates to the HTML DOM match the HTML elements rendered by a JavaServer Faces component.


The application developer is responsible for the server-side processing of AJAX using a web component, such as a servlet. Updates to the JavaServer Faces model data occur outside the scope of the JavaServer Faces technology life cycle request/response processing, so care should be taken to ensure that model data updated by a server-side component is consistent with that managed by the JavaServer Faces technology runtime.

Comparison of Strategies

Below is a table that contains a list of trade-offs for each strategy.

Rendering JavaScript Exactly Once

The JavaScript should be placed in a separate file as mentioned above, to ensure that the JavaScript contents can be cached by the browser.

While the JavaServer Faces component can be used multiple times in a page, the JavaScript inclusion reference should be emitted exactly once -- before the first usage. A good way to do this is to modify the renderer that emits the script tag so that it stores a flag for itself in the request map.  This flag records whether the renderer has written the script out for the current page yet. The following code snippet demonstrates how to add code to the renderer that will store the flag and check its value to determine if the script tag has been rendered:

    ...
    private void renderScriptOnce(ResponseWriter writer, UIComponent component, FacesContext context)
        throws IOException {
        // Store attribute in request map when we've rendered the script such
        // that we only do this once per page
        Map requestMap = context.getExternalContext().getRequestMap();
        Boolean scriptRendered = (Boolean)requestMap.get(RENDERED_SCRIPT_KEY);
                                                                               
        if (scriptRendered == Boolean.TRUE) {
            return;
        }

        // Render script and CSS here
        ...
     }

     private static final String RENDERED_SCRIPT_KEY = "bpcatalog-ajax-script-rendered";

Project Structure and Packaging

One issue that developers must deal with is how to organize their workspace. What should the project conventions be? Generally, this is covered by existing project conventions for JavaServer Faces technology modules and applications. For example, the faces-config.xml file and the TLD files for JavaServer Faces technology are usually kept in the src/conf directory.

But where should you keep the JavaScript files? Should they be kept with the source code files? In most cases, we recommend that the JavaScript files be kept in the src/resources directory. In some cases, you might be using a pre-existing library of JavaScript files, which might be reusable even without the JavaServer Faces components, such as in the case of making a JavaServer Faces component that uses some of those existing JavaScript files. In this instance, the JavaScript library should be viewed as a separate project and should be used only by the JavaServer Faces application.

Another issue to consider is how to package these JavaServer Faces components and JavaScript artifacts into a WAR file or EAR file. The packaging is mostly the same as for other JavaServer Faces modules and applications, but you need to consider where to put the AJAX artifacts, which include the javascript files. Generally, it is recommended that you place the AJAX artifacts with the compiled classes so that the JavaServer Faces components can load them by calling getClass().getResourceAsStream().

In order to use the components within an IDE, there are additional packaging considerations, such as how to make properties visible in IDE property sheets. These considerations differ from IDE to IDE (until this hopefully gets standardized with JSR 273). For a description of how to package your JavaServer Faces component for Sun Java Studio Creator, read http://developers.sun.com/prodtech/javatools/jscreator/reference/techart/jsfcomplibrary.html .

Helpful Hints for Developing AJAX components with JavaServer Faces Technology

• Understand the JavaServer Faces component model. The J2EE 1.4 Tutorial on Creating JavaServer Faces Components describes the necessary artifacts needed to create custom JavaServer Faces components.
• Get a good JavaScript book. JavaScript: The Definitive Guide, 4th Edition By David Flanagan is quite adequate.
• Get familiar with Venkman, the JavaScript debugger in the Mozilla suite.
• Get familiar with the Internet Explorer Script Debugger.
• Visit QuirksMode.org, a great JavaScript/CSS reference site.
• It's generally a good idea to put all your JavaScript code into one file that is referred to using <script> tags. During iterative development, it's a good idea to place this file directly in your server root so you can edit it in place. Then modify your code to refer to it at this location, just during development. When you get everything working, you can switch to using the FacesServlet and PhaseListener style to keep things self contained.

References

For more details on this solution see the JavaServer Faces Technology Auto-Completion Component with AJAX: Design Details and AJAX Progress Bar for JavaServer Faces Technology: Design Details.

May 25, 2005

The JavaServer Faces (JSF) specification provides a set of components with which application developers can build Java server applications. However, it is extremely likely that developers will want to extend JSF by creating custom components. Here we'll explore the process of creating new JSF components, highlighting common "gotchas" and providing guidelines for defining good components. We'll also look at the need for providing design-time metadata, so that component developers can ensure an excellent design-time experience for their custom components.

Before we start looking at components, it is worthwhile to elaborate on "why another framework?" When it comes to the architecture of JSF, it is not a new thing. For example, Apache's Tapestry and Oracle's ADF UIX framework have been around for quite some time and have proven to be very successful. JSF brings what other similar view technologies do not have: backing of a standard specification (JSR 127).

If we look at where we are today, most Web applications are stuck in the 1990s, when much too much effort was put into basic plumbing and not enough into high-level components. Basically, there is limited abstraction or no abstraction over the markup making development of Web applications cumbersome and the applications themselves hard to maintain. A lot of work is forced into the application to make it rich and interactive, with various technologies from applets, plug-ins (Flex), DHTML, and JavaScript. Together, these technologies can make up a very interactive and powerful Web application, but how do you maintain such an application? How do you reuse what you have built? Do you need multiple tools to achieve your goal of an interactive Web application?

These questions lead back to JSF and what it brings to the table—a best-of-breed J2EE framework—and the fact that every major J2EE tool vendor such as Oracle, IBM, Sun, and Borland is behind JSF.

Component developers. Components, components, components: these are the golden nuggets that will make or break the success of JSF. Some vendors are already producing components for external use and for open source communities such as MyFaces (see Resources). But, for JSF adoption to increase we need more components—lots of them—and with richer functionality.

The dearth of existing components and the need for richer component sets mean that getting into the business of providing JSF components is a good opportunity. JSF also allows component authors to sell components based on a recognized J2EE-standard framework (instead of trying to convince customers to use a homegrown framework). Besides the business aspect of creating JSF components, there are also benefits to creating components by using JSF. JSF provides built-in support for aspects that are hard and cumbersome to implement, such as event handling, state saving, expression language, and a standard way to make custom components extensible.

Tool developers. Tool developers need a formal standard that not only makes life easier for end users but also allows the developers to design and develop tools that will ease development of Web applications, or as they are called in this early part of the twenty-first century, J2EE applications.

As you are probably aware, JSF uses different classes for providing component functionality and for rendering the component. Before getting your hands dirty building your first set of components, search the Web for existing components.

There should be a fair amount of components already out there, and in most cases, you can probably get away with writing a new renderer for an existing component. If the component you are looking for cannot be found, it is time to build your own. To build a new component, you should make sure it has distinct server-side behavior and introduces a new behavior, functionality, or definition. If the component exists and you need a new appearance, you just need to create a new renderer (see Figure 1).

Good and Bad of It
An example of good separation between behavior and appearance is the UISelectOne component provided by the JSF Reference Implementation. This component has a distinct behavior and three different renderer types: ListBox, Radio, and Menu. Potentially, you can add other types of renderers that have different appearances but the same behavior.

What distinguishes a good component from a bad component? A good component should have generic properties, event listeners, and specific behavior. The component should not contain markup-specific attributes, such as the "href" attribute; should not write markup or get request parameters; and should work with server events, not client events. It is important to isolate the presentation information from the underlying server-side component (see Table 1).

In addition to the Table 1 information, using JSF facets enhances business developers' user experience developing applications with JSF components. A facet is a kind of child component that has a specific purpose defined by its name. A facet can be viewed as an empty placeholder that can take one child component. A parent component can have multiple facets; an example is a component called panelPage provided by Oracle's ADF Faces component set. This component uses facets to render its children in predefined locations such as the corporate logo (CORPORATE_BRANDING facet) or the copyright statement (COPYRIGHT facet).

Renderers have their own classes and are therefore also subject to good and bad implementations. Writing a good renderer means basically reversing the list of dos for writing a good component. What is really important is that you do not give model access to the renderer. You should also try to use the ResponseWriter as often as possible, which will give tools a better chance of visualizing your component in a WYSIWYG editor. Here is an example of using the ResponseWriter:

public void encodeBegin(
  FacesContext context, 
  UIComponent component) throws 
  IOException
{
  ResponseWriter out = 
    context.getResponseWriter();

  //Pass the component so that 
  //the ResponseWriter can use 
  //it.
  out.startElement(
    "span", component);

  //Pass the "styleClass" 
  //attribute so that it can be 
  //matched.
  Object style = 
    component.getAttributes().
    get("styleClass");
    out.writeAttribute("class", 
    style, "styleClass");
}

You also need to make sure you register your renderer with a render kit. The most widely used rendering language is HTML, but this characteristic doesn't mean that you must use the HTML render kit; you can use any rendering language of your choice, such as SVG or XML.

There are some areas that need improvement and a few areas or gotchas that are not yet covered or will not be covered by the JSF specification. One example is the lack of a strategy for a consistent look and feel. There is currently nothing in the specification that outlines or defines a standard for implementing "themes" or "skinning." An area of improvement would be to make it easier to write a renderer. Today you need to write Java code to create a renderer, but it should be possible to come up with a more declarative solution for writing renderers similar to what is available in ADF UIX.

There is also no support for registering a renderer with multiple render kits and no tool support for testing components across multiple implementations such as MyFaces or Sun's JSF Reference Implementation.

The Good, the Bad, and the Ugly
As a component developer or vendor, you are not locked into any IDE; in fact, if you prefer to use a text editor such as Emacs or VI, you can do so. JSF simplifies J2EE development because it will be easier for tool vendors to create a design-time experience for business developers similar to Visual Basic, using custom-designed and reusable components. Component developers may have the following questions: How do I get tools to support my custom components? Do I have to add anything beyond the required renderer so that my components can utilize all design-time features or display nicely in the tool's visual editor?

The good. As you probably already know, there are plenty of tools available today with various levels of JSF support, and all major tool players—Oracle, IBM, Sun Microsystems, and Exadel—are working feverishly to improve the support for JSF. The JSF expert group clearly thought about tool support when they designed the faces-config.xml file. This XML file is an invaluable source of information that contains, for example, available components and their properties and facets. Not only is the XML file format easily digestible by tools, but also tools can automatically detect the location of a faces-config.xml for a set of components. Tools can, based on information provided in the faces-config.xml file, expose the set of available components at design time.

The bad. The bad thing is that faces-config.xml and TLDs are not very expressive and cannot convey interesting constraints such as valid values, or component enumerations. An example is the Oracle ADF Faces component . This component has an attribute called messageType. The valid values for this attribute are "error", "warning", "info", and "none". Unfortunately, there is no way in faces-config.xml to express that constraint. The faces-config.xml file also cannot indicate relationships between components, such as what would be a valid child for a particular component—for example, a Table component might only accept a Column component as a valid child. These shortcomings can be dealt with by providing these constraints and relationships in design-time metadata.

The ugly. What could turn ugly is if tool vendors define their own proprietary ways of providing design-time metadata. Tool vendors are already asking for additional metadata from component authors so that components can fully utilize the design time, which will lead to component authors providing proprietary solutions for each tool vendor.

The hope. The hope is that the JSF community can agree on standard design-time metadata and that component authors will invest in providing metadata for their components. The most likely way of defining such a standard is through the Java Community Process (JCP). Oracle is working with other JCP members with the goal of proposing a new JSR that would define a standard set of design-time metadata items for JSF components and a mechanism for providing such metadata.

Although the faces-config.xml language allows a component author to express a great deal of information about their components and renderers, it only has standard syntax for expressing a very minimal set of design-time metadata (mainly display-name, description, and icon). Fortunately, the faces-config.xml language is designed with convenient extension points that can be used to hold additional information.

Strong Community
As previously discussed, there is not yet a standard mechanism for supplying additional design-time metadata. However, one proposed solution would utilize the extension points in faces-config.xml (see Listing 1). If you are interested in this issue, there is a thread on the Sun's JavaServer Faces Technology forum devoted to discussing design-time metadata for JSF components.

A crucial ingredient for the continuation of JSF's success and progress is a strong community. If you look at what ASP.Net has done and evaluate what makes this proprietary framework so successful, there is one thing that always pops up: the ASP community. Its community sites have forums with hundreds of daily posts as well as tutorials and content that are updated daily. There are component galleries with free hosting of custom components, which are integrated with the development tools. There are also free versions of basic tools supporting ASP development.

Some of this type of groundwork has already started with projects such as MyFaces and information sites such as JSFCentral, but this is not enough. We cannot hope that a small group or a single person can provide us with a complete set of community sites including daily posts, tutorials, and contents. Now is the time to get involved in Faces!

The JSF community needs one or more neutral hosting sites that provide content such as tutorials, forums, and announcements—and, of course, component galleries. Another area in which the community can provide help in is testing tools. In the spirit of Cactus and JUnit, the community could provide testing tools with a different approach, such as test components and not markup, and send simulated events. For anyone eager to get involved, this possibility would make a good open source project.

Skinning and themes are areas that noncoders could ideally participate in. Noncoders could provide style abstractions to mirror component abstractions using styles, icons, text/translations, and templating.

There is a future beyond HTML; eventually, component authors will provide higher-level components with better customization. These components will be based on other client-side technologies, such as DHTML, SVG, Flex, XUL, and Web Forms (see Figure 2).

The message here is, think components, not markup! JSF is not exclusively for HTML, it is not exclusive to hard-core developers, and it is not exclusive to business developers. There are plenty of opportunities for all types of developers. Finally, don't forget the metadata, and make sure you get involved early in the JSF community.

About the Author
Jonas Jacobi is a senior product manager for JDeveloper at Oracle.