 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 127: JavaServer Faces
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: This specification defines an architecture and APIs which simplify the creation and maintenance of Java Server application GUIs. Please direct comments on this JSR to the Spec Lead(s) Team
Updates to the Original Java Specification Request (JSR) Current JSR Status 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/.
Thank you, Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Amy Fowler E-Mail Address: amy.fowler@sun.com Telephone Number: +1 408 343 1418 Fax Number: +1 408 343 1797 Specification Lead: Amy Fowler, Hans Muller, Java Software, Sun Microsystems E-Mail Address: amy.fowler@sun.com, hans.muller@sun.com Telephone Number: +1 408 343 1418 Fax Number: +1 408 343 1797 Initial Expert Group Membership: ATG Section 2: Request
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:
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.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2EE 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.Specifications for the Java Server development environment: 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
