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().
|