(Updated) JavaServer Faces 1.2 and JavaServer Pages 2.1 Proposed Final Draft Specifications available

I'm pleased to announce the availability of the Proposed Final Draft
revisions of the next release of the JavaServer^TM Faces and
Pages specifications. The Faces spec may be downloaded from < href="http://www.jcp.org/en/jsr/detail?id=252">http://www.jcp.org/en/jsr/detail?id=252>
and the Pages spec may be downloaded from < href="http://www.jcp.org/en/jsr/detail?id=245">http://www.jcp.org/en/jsr/detail?id=245>
We really want feedback! Please use our href="http://forum.java.sun.com/thread.jspa?threadID=617376&tstart=0">Forum
to share your thoughts on the specs. Or you may send feedback to
the comments alias for title="[PUBLIC REVIEW FEEDBACK]">Faces or href="mailto:jsr-245-comments@jcp.org" title="[PUBLIC REVIEW
FEEDBACK]">JSP ( title="[PUBLIC REVIEW FEEDBACK]">jsr-252-comments@jcp.org and href="mailto:jsr-245-comments@jcp.org" title="[PUBLIC REVIEW
FEEDBACK]">jsr-245-comments@jcp.org respectively) .

In this entry, I link to a comprehensive high level outline of the
changes to the spec since the 1.1 release of the Faces spec. I've
decided include changes present in the href="http://jcp.org/aboutJava/communityprocess/edr/jsr252/">December
Early Draft Release, the href="http://jcp.org/aboutJava/communityprocess/pr/jsr252/">April Public
Review Release and the current Proposed Final Draft release for
completeness. As such, this entry repeats some information from my href="http://weblogs.java.net/blog/edburns/archive/2005/04/javaserver_face_1.html">
blog entry on the April Public Review Release. If you're looking
for what's new since that the Public Review release only, please consult
href="https://javaserverfaces-spec-public.dev.java.net/issues/buglist.cgi?component=javaserverfaces-spec-public&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=7%2C+8%2C+12%2C+29%2C+32%2C+47%2C+50%2C+53%2C+54%2C+56%2C+68%2C+73%2C+75%2C+76%2C+78%2C+79%2C+80%2C+81%2C+82%2C+84%2C+85%2C+86%2C+87%2C+94%2C+98%2C+44%2C+79&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&namedcmd=IssuesResolvedPRtoPFD&newqueryname=&order=Reuse+same+sort+as+last+time&Submit+query=Submit+query">this
issue tracker query.

Keep in mind this is a high level outline, for details, I
encourage you to read the relevant sections of the spec itself.

Before we get to the outline, here is a brief summary of the main
changes:

• Unified EL

  The expression language used in Faces, which
  was inspired by the expression language used in
  JSTL and JSP, has been generalized and extracted
  into its own top level javax.el
  package. The EL is agnostic of the technology
  hosting it, such as JSP or Faces, and is intended
  to be generally useful in the same way one can use
  OGNL in a variety of applications. Faces now has
  deprecated its internal EL in favor of using the
  Unified EL.

• New Tree Creation and Content Interweaving
  Model for Faces applications that use JSP

  While it is perfectly acceptable to use Faces
  without using JSP, many people find their
  productivity increases when using these two
  technologies together. Unfortunately, as amply
  documented by href="http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html">Hans
  Bergsten in his article at onjava.com, there
  were some integration cases that didn't work as
  expected. By changing the specification of the
  implementation of the Faces ViewHandler for JSP,
  as well as changing the JSP custom tag base class
  used by all Faces component tags, these problems
  have all been resolved.

• Integration with JSTL

  Another long standing problem was in using JSTL's
  <c:forEach> tag to contain Faces input
  components. Because JSP has no notion of a postback, it was
  not possible to apply the values correctly to the nested input
  components on postback. By introducing some new concepts into
  the EL, it is now possible to fully use
  <c:forEach> with any kind of Faces
  component. This will require a new release of JSTL, which
  will also be present in J2EE 5, along with Faces and JSP.

• Back Button issues and Multi Frame or Multi Window
  Faces Apps

  Due to a deficiency in the State Management API using Faces
  in Multi Frame or Multi Window applications presented some
  problems. The browser back button also could cause
  application state to become confused. These problems have now
  been fixed.

• Associating a message with a particular component in
  the page.

  Previous revisions of the spec didn't allow for
  dynamically including the label of a component in an error
  message for that component. New spec features now allow for
  this to happen.

  It is now possible to override the conversion or
  validation message that is displayed to the user on a
  per-instance basis. For example:

  <pre>
  
  &lt;h:inputText value="#{bean.value}" 
                  requiredMessage="#{bundle.requiredMessage}"
                  converterMessage="#{bundle.converterMessage}"
                  validatorMessage="#{bundle.requiredMessage}"&gt;
    &lt;f:validateLongRange maximum="1" minimum="10"/&gt;
  &lt;/h:inputText&gt;
  
  </pre>

• AJAX support

  As you should all know by know, AJAX is mainly a
  component thing, but there are some things the basic JSF
  framework can do to make things a little easier for those
  writing AJAXian JSF components. Even without these features
  (ie, in JSF 1.1), href="https://bpcatalog.dev.java.net/nonav/ajax/jsf-ajax/frames.html">it's
  very easy to write AJAX components for JSF and easier
  still to use them.

  Specify that the FacesServlet should look
  for an init-param called
  javax.faces.LIFECYCLE_ID to identify the Lifecycle to be
  used for processing this request. This approach allows you
  to map different instances of the FacesServlet
  with different lifecycles. For example, one mapping for
  standard JSF requests and another for AJAX JSF requests.

  Specify the name of the state saving parameter so that
  AJAX scripts can manually post back the state to the server
  using XMLHttpRequest, therefore enabling the AJAX processing
  code to have access to the full view. This approach was
  used in the href="http://weblogs.java.net/blog/edburns/archive/2005/05/ajaxian_faces_p.html">Progress
  Bar JSF component. The name of the parameter is
  javax.faces.ViewState.

• Expose an application wide ResourceBundle to the EL.

  We have added a new <resource-bundle> element to
  the faces-config that allows you to list zero or more
  resource bundles that should be exposed to the EL using the
  new ELResolver chain. Doing this allows performance
  optimizations that prevent the need to create a
  ResourceBundle for every request.

• API classes use generics

  In response to strong Expert Group demand, we have
  applied Java SE 5.0 Generics to the JSF api. Therefore, the
  minimum JDK requirement for JSF 1.2 is Java SE 5.0. I'm
  told that it's possible to retroweave a binary to make it
  run under 1.4, but of course that configuration is not
  supported or recommended by Sun.

All of these features and more are currently available in the JSF
implementation found in Sun's Open Source Appserver, href="https://glassfish.dev.java.net/">glassfish.

Now, the outline of changes is available href="http://weblogs.java.net/blog/edburns/archive/outline.html/20050825-outline.html">here.

Technorati Tags: edburns