JavaServer Faces 1.0 Specification Errata

C001

  Made the "for" attribute no longer required for the outputLabel tag.
  This is necessary when tools want to allow the user to stick the label
  on the page before associating the component with it.

C002

  renderkit spec changes around SelectManyMenu, SelectManyList,
  SelectOneRadio, SelectManyCheckboxlist

  M doc/standard-html-renderkit.xml

    - Remove span around "select" tags in SelectManyMenu, SelectManyList,
      SelectOneMenu and SelectOneList.

    - Remove span around SelectOne radio buttons and SelectMany checkboxes.
      Render "id", "style", "styleclass" as part of outer table.

C003

  Introduce the concept of "no value" for SelectOne and SelectMany.

  M src/javax/faces/component/UIInput.java

  - modify isEmpty() method to consider values that are zero length array
    or List instances to be empty.

C004

  Portlet compatability

  M src/javax/faces/webapp/UIComponentTag

  - Remove compile time dependency on Servlet API classes.  Get the
    classes at runtime from the pageContext ivar.

C005

  Spec section 2.5.2.4 

  Remove LIMIT messages, a hold over from a deprecated concept

C006

  Spec sections 9.4.12 - 9.4.14 

  Make sure that all validator and converter IDs in the spec match
  what's in the code.

C007

  Spec section 9.4.10

  <f:selectItems>

  Section 9.4.10 contains a number of errors: * The description of the
  getComponentType() return value omits the "javax.faces" prefix. * The
  list of acceptable data types for the "value" attribute doesn't match
  the data type for UISelectItems.

C008

  Spec section 9.4.9 

  The attributes table for <f:selectItem> in 9.4.9 states that the
  "itemValue" attribute takes a String but it should be Object to match
  the type of the UISelectItem property.

  The syntax section in 9.4.9 for <f:selectItem> is missing a couple of
  right square brackets to mark the end for optional attributes. 

  Spec section 9.4.8 

  Both syntax sections for <f:param> in 9.4.8 are missing the "binding"
  attribute, which is included in the attributes table.

C009

  Spec section 9.4.3

  The "timeZone" attribute for <f:convertDateTime> in 9.4.3 is
  described to only accept a TimeZone instance, but it also accepts a
  String. 

  The "locale" attribute for <f:convertDateTime> and
  <f:convertNumber> in 9.4.3 and 9.4.4 is described to only accept
  a Locale instance, but it also accepts a String

C010

  UISelectOne and UISelectMany can fire spurious ValueChangeEvents

  M jsf-api/src/javax/faces/component/UIInput.java

  - refactor the validate() method so that straight up validation is
    separable from "membership test" validation, as done in UISelect*.  Do
    this by introducing two new protected methods, which can be overridden
    by subclasses.

    getConvertedValue()

    validateValue()

    The latter is overridden in UISelect* to first call the superclass
    version, to do straight up validation, then upon return to do the
    "membership test" validation.

  M jsf-api/src/javax/faces/component/UISelectMany.java
  M jsf-api/src/javax/faces/component/UISelectOne.java

  - replace validate() override with validateValue() overrides.

  M jsf-api/test/javax/faces/component/UISelectManyTestCase.java

  - fix this testcase.  It was making incorrect assumptions that have been
    fixed by this change-bundle.

C011

  javax.faces.webapp.FacetTag doEndTag() override unnecessary.

  - Since TagSupport does this, we don't need to override it here.

C012

  UIViewRoot getRenderKitId() doesn't consult the ViewHandler

  Per a later EG thread, the EG decided it would be better to have this method
  return null if the renderkitid was not explicitely set as in 
  javax.faces.application.ViewHandler.createView.

M src/javax/faces/component/UIViewRoot.java
- getRenderKitId method  - unless renderKitId has been set - null will be returned.



C013


Date:         Wed, 17 Mar 2004 15:32:41 -0800
From:         Adam Winer <adam.winer@ORACLE.COM>
Subject:      [BUG] DoubleRangeValidator message formatting

When DoubleRangeValidator constructs an error message, it passes
java.lang.Double objects to MessageFormat. The RI's default messages
simply say use "{0}" and "{1}", so these Doubles will simply be
toString()'d, and are therefore not properly localized. A possible
temporary solution is to change these to {0, number} and {1, number}. A
better solution would be keep using {0} and {1} and stop passing
java.lang.Double objects; instead, use the Converter registered on the
component, and if that is null, use the Converter registered on the
Application with the id "javax.faces.Double". This would ensure that the
values displayed in error messages are formatted identically to the
values displayed in the field. At any rate, we do need to specify what
type of object is passed for {0} and {1}, and that in turn implies which
of these two solutions we need to use. Unless we specify this, it is
impossible to portably override the messages used by
DoubleRangeValidator. Finally, this all applies equally to
LongRangeValidator, and somewhat less to LengthValidator.


Item #: 005703
Type: apichange richange specedit
area: messages
owner: edburns
Release: 1.1

C014

  MethodBinding getType() value for void

  The JavaDocs for the MethodBinding getType() method says that null
  is returned for a void return type. It would make more sense to
  return Void.class.

C015

   Invalid parameter name in FactoryFinder JavaDocs

   The FactoryFinder JavaDocs refers to the config file context param as
   "javax.faces.application.CONFIG_FILES" but the spec doc has it as
   "javax.faces.CONFIG_FILES" in 10.3.2

C016

   The JavaDocs description of the ResultSetDataModel getRowData()
   method doesn't specify that the returned Map must use a
   case-insensitive Comparator.  Make this specification explicit.

C017


From:         Hans Bergsten <hans@GEFIONSOFTWARE.COM>
Subject:      [BUG] Incorrect JavaDocs for DataModelEvent

JavaDocs for the DataModelEvent getRowIndex() method says that 0 is returned if the event isn't for a specific row. It must be -1, since 0 is a valid index.

EB> Check with Craig on this one.  The choice of 0 index or 1 index was
EB> problematic IIRC.

Item #: 005691
Type: apichange 
area: component
owner: edburns
Release: 1.1

C018

   The defaults for showDetail and showSummary for UIMessage are reversed
   in the JavaDocs for the getter methods. It claims that showDetail is
   false and showSummary is true by default, but the code (correctly)
   has them as true and false, respectively.

C019

   The UIForm class overrides saveState() to reset the "submitted" flag,
   but this is an example of how the saveState() method should _not_ be
   used, since it's not necessarily not called for all state-saving
   scenarios. The method should be removed, because the "submitted"
   property is also (correctly) reset by the renderer in the decode()
   method.


C020

  The Checkbox renderer for UISelectMany and the Radio renderer for
  UISelectOne renders the <input> elements within <label>
  elements. The problem is that the "for" attribute is set to the client
  ID for the UISelectOne/Many component on each of the <label>
  elements. The "for" attribute shouldn't be used at all when the
  <label> element encloses the labelled element, and when it is
  use, it must refer to the labelled element. The current RI behavior
  (and the spec) is incorrect on both accounts.

  There's two styles of <label> (1) <label for="foo">The
  Label</label> <input id="foo" ...> (2) <label>The
  Label <input id="foo" ...> </label> Moreover, form #2 is
  deprecated and considered highly undesirable by our accessibility
  experts over here.

C021

  The TLD description of <h:selectOneRadio> doesn't mention that
  <label> elements are rendered to hold the labels, and
  incorrectly refers to the ListboxRenderer description for how to
  render <option> elements.


C022


  TLD description of <h:selectMany> says that the "size" attribute
  is set either to the value specified by the action element's "size"
  attribute or to the number of items (i.e., the description that
  applies to the Listbox renderer), but there's no "size" attribute
  defined for this action element (which is correct, of course).

C023

  This thread in the forum deals with problems using the
  <h:outputLabel> action:
  <http://forum.java.sun.com/thread.jsp?forum=427&thread=500037&tstart=0&trange=15>
  The thread comes to the conclusion that the label value must be
  specified as a child component, but that's not true: the renderer
  renders the <label> tag in its encodeBegin() method and the
  </label> tag in its encodeEnd() method, and any text in between
  (generated by a component or just plain template text) ends up as the
  <label> element's value. What I consider a bug is that the
  UIOutput component's value isn't used as the <label> element
  body instead. There's a "value" attribute for the
  <h:outputLabel> action element, but it's ignored. Neither the
  render kit docs nor the HTML tag library docs say anything about where
  the <label> element's value should come from.

  Another reason for the problem described in the thread is that the
  component identifed by the "for" attribute must exist when the
  <h:outputLabel> element is processed, i.e., appear before the
  <h:outputLabel> element in the JSP page or have been added
  programatically.

  The "for" attribute processing, now that's a nasty bug, since the
  label will appear before the tag it labels 99.9% of the time.
  Including the <h:outputLabel> in a "rendersChildren" tag works
  around the problem, but that's not perfect.

  The best I can come up with is that, in the case where "for"
  does not point to any known component, the LabelRenderer
  should assume it's a component that doesn't *yet* exist, and run
  the equivalent of UIComponentBase.getClientId()'s logic over
  "for".  Ugh, but it would largely work.

  EB> Yes, but only for cases where the component and the label are in the
  EB> same naming container.

C024


   The Javadocs for EditableValueHolder getSubmittedValue() says that this
   method should only be called by decode() and validate(). This is
   incorrect (the comment belongs to setSubmittedValue()). This method
   should be called by encodeXXX() methods.

C025

   The UIComponentTag setProperties() Javadocs says that it sets the
   componentId, component, rendered and rendererType for the component
   if the same properties are set for the tag handler, but it only sets
   the last two (I don't even know what the first two are supposed to
   be).

C026

  Nesting dataTable within dataTable didn't work in 1.0.  Make it work in 1.1.

C027


4996223 Table 5.1 action component property method signature conflicts
        with description

C028

Issue id: JSFA59 BACK button

Description: 
          What should the spec say about the eternal issues of dealing with
    a browser user using the BACK button, such as transaction tokens to
    avoid processing the same form submit more than once?  Note that tokens
    should be scoped to specific forms, not a global property of a JSF
    implementation (i.e. probably don't want one on search forms).

Date:         Wed, 24 Mar 2004 13:23:19 -0800
From:         Hans Bergsten <hans@GEFIONSOFTWARE.COM>
Subject:      [BUG/RFE] Command links and Back button behavior

There are numerous reports about problems with the browser back button
when combined with command links in the forum, for instance this one:

   <http://forum.java.sun.com/thread.jsp?forum=427&thread=496856>

It's very simple to reproduce:
1) Create a page with command links, e.g., created by <h:dataTable>
    for a number of rows, bound to an action method that returns an
    outcome which leads to a redirect to another view.
2) Run the page and click on one link. Redirects correctly.
3) Use the back button to return to the first page.
4) Click on another link. Results in an IllegalStateException.

There are many variations on this, but the main problem seem to be
with the JavaScript produced by the Command/Link renderer. The "onclick"
handler sets a hidden field for command link and submits the form. The
problem is that there's one hidden field per rendered link:
1) The first time I click a link, its hidden field is set.
2) When I use the back button, the hidden field is not restet (it's
    part of the browser's page state).
3) If I click another link, yet another hidden field is set, so
    during decoding _two_ ActionEvents fire. Processing the first
    leads to a redirect (committing the response). Processing the
    second leads to a redirect, but since the response is committed,
    this results in an IllegalStateException.

With a regular forward navigation, this may be even worse, because
you have no idea in which order the events are handled and there's
no exception. Instead, you may simply get the wrong result.

Note that this has nothing to do with server vs. client state saving,
as some reports claim.

AFAIK, the fix is simple: use a single hidden field for all command
links and use the value of this field to decide which command link
triggered the submit. Unfortunately, the renderer docs are too
explicit to allow this to be treated as an RI bug fix, so we need an
errata to fix it.

Item #: 005711
Type: apichange richange 
Priority: 
      Low

area: lifecycle
owner: edburns
    
Release: 1.1

C029

      "enabledClass"/"disabledClass" attributes only specified for
      selectmany_checkbox, selectone_radio.  They should be specified
      for other "select" components as well (components with nested
      select item(s)).

M doc/listbox-attrs.xml
  - generated from listbox-props
M doc/listbox-props.xml
     - added "enabledClass"/"disabledClass"
     this will add these attributes for selectmany_listbox, selectone_listbox
A doc/menu-attrs.xml
   - generated from menu-props
A doc/menu-props.xml
   - contains "enabledClass"/"disabledClass"
     this will add these attributes for selectmany_menu, selectone_menu
M doc/standard-html-renderkit.xml
  - added menu-props definition;
  - added menu-attrs definition;
  - added menu-props for HtmlSelectManyMenu, HtmlSelectOneMenu component entries
  - added menu-attrs for selectmany-menu, selectone-menu renderer entries 

C030

[JSFA170]

AW> Recommendation: add the following element to the DTD in
AW> JSFv1.1:

AW> <facet>
AW>    <description/>  (Usual meaning)
AW>    <display-name/> (Usual meaning)
AW>    <icon/>         (Usual meaning)
AW>    <facet-name/>   (actual name of the facet)
AW>    <facet-extension/> (impl specific extension capability)
AW> </facet>

AW> ... and support adding <facet> (arbitrary numbers)
AW> inside of both <component> and <renderer>.

C031

Adding a convenience method to FacesContext:

   /**
    * Adds a page-level message that is not tied to any
    * specific component.  This is commonly used for messages
    * generated by actions, but can be used for any such
    * page-level message.
    */
   public void addPageMessage(FacesMessage message);

... that is nothing more than a cover for passing "null"
as the clientId to FacesContext.addMessage().