The proposed final draft 3 for JSR 152, JavaServer Pages 2.0 Specification, is available for public review. This JSR is to develop the next revision of the JavaServer Pages specification.
Here's a description of the JSR from the above URL:
The use of products based on the JavaServer Pages(tm) (JSP) specification in the Java community continues to grow. The users include:
- Containers - Page Authoring tools - Integrated Development Environment - Frameworks - Custom Tag Libraries - Web and Web Application Designers
This wealth of feedback and ideas provides direct input into what parts of the JSP specification are most beneficial, which parts need improvement and which features are missing. This JSR requests the creation of an expert group (EG) to drive the next version of the JavaServer Pages(tm) specification using this input, as well as accumulated expertise from the Expert Groups that worked in the previous versions of JSP.
We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as oportunistic improvements.
The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated.
* Use of JSP to author custom actions
JSP 1.2 has several mechanisms for providing a reusable abstraction: static include directives, dynamic include actions and custom actions. Of these, custom actions are the most flexible ones, but they need to be written in Java, which means that a page author must request the help of a Java developer. Furthermore, writing a custom action that uses other custom actions is quite error-prone. It would be very valuable to add a mechanism that would allow a page author to easily abstract a JSP fragment into a new custom action that later can instantiated and used.
A number of participants in the JSP community have proprietary mechanisms that provide this type of functionality. We would like to build on this expertise to deliver a mechanism that could be used for this.
* Expression Language support in container
A common usage pattern for JSP pages involves abstracting away all computation in the JSP page into custom actions or JavaBean components, instantiated or invoked within the JSP page, or in actions that happen before the JSP page is invoked. In these pattern, the computation that still needs to be described within the page can be characterized as expression evaluation. In JSP 1.2, these expressions must be described using Java expressions, even when in many cases the JSP page author thinks of the expression as operating on JavaBeans objects. Also, recently we have started seeing uses where the key abstraction is that of XML nodes.
The JavaServer Pages standard Tag Library (JSPTL) is being developed in the Java Community Process as JSR-052. The JSPTL EG has reacted to this use pattern by adding support for a 'simple expression language' in the current drafts of the specification. This expression language support is limited to the custom actions in JSPTL and cannot be used in any other custom tag library without changes to the code of the library.
The simple expression language approach has been explored in a number of different forums, including ECMAScript, other JSP tag libraries, some servlet-based but non-JSP-based projects and some non-Java based projects.
We would like to incorporate support for an expression language at the container level in the next revision of the JSP specification. This would make the expression language available when using any existing custom action, and would enable the container to perform optimizations on the expressions.
* Additional Community Feedback
We want to incorporate feedback from a number of different ongoing efforts:
- JSPTL - JavaServer Faces - Web Services-based effort - Struts and other frameworks
Two specific areas that we would like to improve are:
* Improve localization; in particular, JSP 1.2 has some problems with identifying some encoding of the JSP pages.
* Improve page authoring support; in particular, the Tag Library Descriptor file is still missing some useful information.
Finally, if the request for a Servlet 2.4 specification is granted, we will use it.
* One theme: simplified use
One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have. This while the full power and flexibility of JSP is available for those projects when it is appropriate.
Previous Topic
