Outline of Changes to JavaServer Faces Spec since 1.1

Features that are unavailable as of this writing are listed in gray, available features are listed in non-gray text. Available features are present in the latest release of the official Faces implementation on java.net which continues to run on J2EE 1.3 containers. Note that the content in section IV is mostly available.

I. Unified EL

  A. Major User visible differences between Faces EL and
     Unified EL

    1. Pluggability: now you provide an ELResolver, before
       you provided a PropertyResolver and/or a
       VariableResolver.

    2. Deprecated APIs: everything in javax.faces.el is
       deprecated.  Everything that touches things in that
       package is also deprecated.

    3. New package, javax.el, delivered as part of the JSP
       spec.

  B. Minor User visible differences between Faces EL and Unified EL

    1. application.getPropertyResolver()/application.getVariableResolver(),
       no longer return the head of legacy VR chain

    2. PropertyResolver().getType() returns the type based
       on the setValue() while our previous implementation
       based it on getValue(). Since the spec language is
       vague about this, we decided not to document this.

    3. Resolution of implicit objects is no longer
       overridable.  This means you can't create a managed
       bean with a name equal to any of the implicit
       objects.

  C. Major user-invisible differences 

    1. EL implementation inside faces is gone, impl comes
       from JSP container.

II. JSP and the EL

  A. Major differences

    1. New tag hierarchy: UIComponentELTag

    2. New "setter" types for JSP tags, see
       UIComponentELTag.

    3. jsp-version in the TLD is used to enable/disable
       interpretation of #{} by the container.

III. Tree Creation and Content Interweaving TCCI

  A. Why we need it

    See Hans Bergsten's article at http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html.

  B. How it works

    I'll write another blog about this when we get closer to
    having an implementation available.

  C. User visible changes

    1. New tag hierarchy: UIComponentClassicTagBase and
       UIComponentELTag.


IV. Miscellaneous changes

  These all correspond to java.net issue tracker issues, but
  numbers below are not the real issue numbers.  Here is a
  link
  to a query for all the below issues.

  A. JSP layer

    1. Provided an additional "binding" attribute for the
       core Converter, Listener and Validator tags that
       would be used as a ValueExpression to alternatively
       create the Converter, Listener or Validator
       instance. Please see Section 9.4 "JSF Core Tag
       Library".

    2. When a resource lookup is done on the java.util.Map
       (loaded from <f:loadBundle>) using a key, and
       the key is not found in the Map, return the literal
       string ???KEY??? where KEY is the key being looked up
       in the Map (instead of throwing a
       MissingResourceException). Throw a JspException if
       the named bundle identified by <f:loadBundle>
       does not exist. Please see Section 9.4.7
       "<f:loadBundle>".

    3. Provided additional I18n attributes "dir and "lang"
       for the tags: <h:outputText>,
       <h:outputFormat>, <h:messages>,
       <h:message>. Please see Section 8.5 "Standard
       HTML RenderKit Implementation" for descriptions of
       these components.

    4. Made UViewRoot a source of PhaseEvent(s) for all
       phases of the request processing lifecycle except
       RestoreView. Provided additional "before" and "after"
       phase listener attributes for the <f:view>
       tag. Please see Section 4.1.17 "UIViewRoot" for
       details.


    5. Avoid EL expression evaluation for "value" attribute
       on "AttributeTag". "AttributeTag" now passes the
       expression to UIComponent for evaluation.


    6.  Clarify the specification with respect to constraint
        violations for tags in the Core Tag Library.

  C. Extensibility changes

    1. Enhanced the usage of the "Decorator Pattern" for
       ViewHandler, StateManager and ResponseWriter classes
       by providing abstract wrapper classes to make it
       easier to override a subset of the total methods for
       those classes. Please see Section 10.4.5 "Delegating
       Implementation Support" for more details.

  D. Config/Startup changes

    1. Migrated over to using XML Schema (from DTD) for
       configuation file validation. Please see Section 1.1
       "XML Schema Definition".

       Here is a diagram of the schema.  Click the diagram
       to show the schema fully expanded.  You may have to
       zoom and pan the expanded image.





    2. Clarify the specification with respect to
       "Application Startup Behavior". Allow implementations
       to check for the presence of a servlet-class
       definition in a web application deployment descriptor
       as a means to abort the configuration and save
       startup time.

    3. Application.addELResolver() can be called until first
       request has been served.


  E. Component/Rendering changes:

    1. Clarified the behavior of PhaseListener implementations in
       the following way: they must guarantee that if
       "beforePhase()" is called, then "afterPhase()" must
       also be called, regardless of any thrown
       exceptions. Please see Section 11.3 "PhaseListener"
       for more specifics.

    2. Provided a new facet for DataTable Renderer that allows the
       rendering of a table caption" element immediately
       following the "table" element. Also provided style
       sheet attributes for this new element. Please see
       Section 8.5 "Standard HTML RenderKit Implementation"
       for a descrption of this component.

    3. Clarified the use of a string literal for the "action"
       attribute on ActionSource components.

    4. Improve XHTML compliance by rendering both "lang" and
       "xml:lang" attributes.

    5. Enabed "protected" access to internal "DataModel" in
       UIData.

    6. Introduced a new optional "layout" attribute on the
       "PanelGroup" component that controls the rendering of
       either a "div" or "span" HTML element. Please see
       Section 8.5 "Standard HTML RenderKit Implementation"
       for more details.

    7. Introduced a new optional "label" attribute for input
       components that will provide an association between a
       component, and the message that the component
       (indirectly) produced. Please refer to Section 8.5
       "Standard HTML RenderKit Implementation" and Section
       2.5.2.4 "Localized Application Messages" for more
       details.

    8. Added headerClass and footerClass attributes at the
       "h:column" level. Please see Section 8.5 "Standard
       HTML RenderKit Implementation" for more information.

    9. Added standard converter messages. Please see Section
       2.5.2.4 "Localized Application Messages" for more
       details.

    10. Specify that the event queue should be cleared after each
       phase (except RestoreViewPhase and RenderResponse) if
       "responseComplete" or "renderResponse" has been set
       on the FacesContext.

    11. <h:messages> now renders HTML list elements ("<ul>","<li>")
       if the "layout" attribute is "list" or the "layout"
       attribute is not specified. If the "layout" is
       "table", an HTML "table" element is rendered instead
       of an outer "span". Please see Section 8.5 "Standard
       HTML RenderKit Implementation" for more details.

     12. Make the "commandButton" "image" attribute render the same
       as the "graphicImage" "img" attribute for
       consistency. Please see Section 8.5 "Standard HTML
       RenderKit Implementation" for more information.
       
    13. For postback requests, in the "RestoreViewPhase", during
       ValueExpression examination for each component in the
       component tree, specify that calling the setValue()
       method on each ValueExpression, should be done in a
       "parent-first" fashion, calling the setValue() method
       and then traversing the children.

    14. Allow the resetting of an input components value by
       introducing a resetValue() method on UIInput.

    15. Permit the passing of a null value to
       SelectItem.setValue().

    16. Specify the algorithm used for client id generation as well
       as provide a way to allow the page author to specify
       exactly what the client Id should be, and preventing
       faces from altering it.

    17. Allow an application to specify multiple render kits by
       introducing an optional "renderKitId" attribute on
       "<f:view>". It is no longer required to write a
       custom ViewHandler to incorporate a different render
       kit. Please refer to Section 8.3
       "ResponseStateManager" and Section 9.4.19
       "<f:view>" for more details.

  F. State Saving/Lifecycle

    1. Clarify that for client side state saving, the state should
       be encrypted for security.
          
    2. Provide a unique window identifier (in addition to the
       "viewid") to accomodate applications that have
       mutiple instances of the same view, but perhaps in
       different browser windows or frames.

    3. Introduced a mechanism to detect if a request is a
       postback.