The JSR-127 expert group is actively developing the Public Review
Draft of the
JavaServer Faces specification. In addition, early access versions
of the
reference implementation will become available during the process,
in order to
get developer feedback before the specification goes to Final Draft.
For more
information about early access releases, see
http://java.sun.com/j2ee/javaserverfaces/.

2.1 Please describe the proposed Specification:

The Servlet/JSP environment provides a powerful model for creating web
applications, however it defines no APIs specifically for creating the client
GUI. To build a JSP page that contains one or more HTML forms, a developer
must manage the form's GUI state and build a mechanism to dispatch from
incoming HTTP requests to component specific event handling methods. When
constructing a web site that provides a complex GUI, developers often create
special purpose infrastructure that simplifies re-using form parts and
facilitates the process of applying sweeping style and behavioral changes
to all of the GUI elements on the site. Over time, the specialized
infrastructure created to support all of these tasks tends to take on a
life of it's own. Unfortunately the idiosyncratic qualities of a particular
site's GUI software make it difficult to take advantage of generic level
programming tools and environments. Ideally an off the shelf tool would
simplify high level tasks like arranging and reusing GUI components and
interconnecting component state and input handling with the objects that
define the application's behavior.

This is a proposal to define a standard set of JSP tags and Java classes
that simplify building Java Server application GUIs. Beyond addressing a
common problem, creating a standard way to define complex HTML forms and
other common GUI elements will enable tools vendors and third party component
vendors to focus their energy on a single component framework for JSP/servlets.
It will also help bridge the gap between conventional GUI toolkit developers
and web based GUI developers by providing familiar APIs for GUI components,
component state, and for rendering and input processing. Comprehensive
support for internationalization and basic input validation will ensure that
developers include these features in the first release of their applications.

The following 8 design goals represent the focus of this proposal:

Create a standard GUI component framework which can be leveraged by
development tools to make it easier for tool users to both create high
quality GUIs and manage the GUI's connections to application behavior.

Define a set of simple lightweight Java base classes for GUI components,
component state, and input events. These classes will address GUI lifecycle
issues, notably managing a component's persistent state for the lifetime
of its page.

Provide a set of common GUI components, including the standard HTML form
input elements. These components will be derived from the simple set of base
classes (outlined in #1) that can be used to define new components.

It is understood that many of the problem spaces targeted by this JSR are
already being addressed in other projects. One prime example of such a project
is the Jakarta open source project, Struts. However, this JSR is aimed at
creating a standard for Java server application GUIs, which will serve to
unify what's become a fragmented area and strengthen support in tools and
other third party products. The expert group will work to determine where
there are synergies and overlap with existing efforts, and ensure this
specification draws appropriately from such projects.

This JSR is viewed as synergistic with the JSP Standard Tag Library project
(JSPTL, JSR-052), as JSPTL does not include GUI-related APIs.

Additionally, work continues in the W3C to evolve relavent web technologies
(XHTML, XForms) and the expert group will track these efforts to ensure the
proposed specification includes enough flexibility to evolve with these
technologies as needed.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification will establish a standard API for creating Java Web
application GUIs, which will eliminate the burden of creating and maintaining
GUI infrastructure for developers.

2.4 Why isn't this need met by existing specifications?

The Servlet/JSP APIs define no GUI structure beyond emitting the appropriate
HTML for the client. There is no model for representing GUI elements as
manipulable, stateful objects on the server, and no standard mechanism for
dispatching client events back to specific methods in the server application.
There are no standard APIs for supporting internationalization, localization,
or accessibility.

The existing Java specifications for creating GUIs, AWT and Swing, were not
designed for modeling GUI elements within an HTML page across an HTTP
connection, which is a scenario requiring significantly different rendering
and event models. However, since a design goal of this JSR is to provide a
GUI paradigm which is familiar to developers, applicable designs and APIs,
such as the JavaBeans event model, will be drawn from these and other
existing GUI toolkits.

2.5 Please give a short description of the underlying technology or technologies:

See Specification description in Section 2.1.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.servlet.ui

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Yes. APIs to support internationalization and localization are a key design
goal of this JSR.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No such changes are anticipated. The existing GUI specifications, AWT and Swing,
are targeted for traditional object-oriented GUI development and will continue
to be supported.

2.11 Please describe the anticipated schedule for the development of this
specification.

The final schedule will be determined by the expert group, however the target
for the Community Draft specification is Fall 2001.

2.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.

Most of the working group communication will happen via email discussion.
There will be a face-to-face meeting to initiate the working group activity.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

This JSR specification will include a new Java class library which hooks in
appropriately with the Servlet 2.2 API and an associated JSP Tag library based
on the JSP 1.1 specification. Note that the revisions to these APIs,
Servlet 2.3 and JSP 1.2, are currently in progress, however it is not
anticipated that this JSR will have any dependencies on functionality
introduced in these revisions.