JavaServer Faces 1.0 Specification ErrataC001 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 conceptC006 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 StringC010 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.C013Date: Wed, 17 Mar 2004 15:32:41 -0800From: Adam Winer <adam.winer@ORACLE.COM>Subject: [BUG] DoubleRangeValidator message formattingWhen DoubleRangeValidator constructs an error message, it passesjava.lang.Double objects to MessageFormat. The RI's default messagessimply say use "{0}" and "{1}", so these Doubles will simply betoString()'d, and are therefore not properly localized. A possibletemporary solution is to change these to {0, number} and {1, number}. Abetter solution would be keep using {0} and {1} and stop passingjava.lang.Double objects; instead, use the Converter registered on thecomponent, and if that is null, use the Converter registered on theApplication with the id "javax.faces.Double". This would ensure that thevalues displayed in error messages are formatted identically to thevalues displayed in the field. At any rate, we do need to specify whattype of object is passed for {0} and {1}, and that in turn implies whichof these two solutions we need to use. Unless we specify this, it isimpossible to portably override the messages used byDoubleRangeValidator. Finally, this all applies equally toLongRangeValidator, and somewhat less to LengthValidator.Item #: 005703Type: apichange richange speceditarea: messagesowner: edburnsRelease: 1.1C014 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.2C016 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.C017From: Hans Bergsten <hans@GEFIONSOFTWARE.COM>Subject: [BUG] Incorrect JavaDocs for DataModelEventJavaDocs 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 wasEB> problematic IIRC.Item #: 005691Type: apichange area: componentowner: edburnsRelease: 1.1C018 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 ...> (2) <label>The Label <input ...> </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.C0274996223 Table 5.1 action component property method signature conflicts with descriptionC028Issue id: JSFA59 BACK buttonDescription: 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 -0800From: Hans Bergsten <hans@GEFIONSOFTWARE.COM>Subject: [BUG/RFE] Command links and Back button behaviorThere are numerous reports about problems with the browser back buttonwhen 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 bewith the JavaScript produced by the Command/Link renderer. The "onclick"handler sets a hidden field for command link and submits the form. Theproblem 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, becauseyou have no idea in which order the events are handled and there'sno 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 commandlinks and use the value of this field to decide which command linktriggered the submit. Unfortunately, the renderer docs are tooexplicit to allow this to be treated as an RI bug fix, so we need anerrata to fix it.Item #: 005711Type: apichange richange Priority: Lowarea: lifecycleowner: edburns Release: 1.1C029 "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-propsM doc/listbox-props.xml - added "enabledClass"/"disabledClass" this will add these attributes for selectmany_listbox, selectone_listboxA doc/menu-attrs.xml - generated from menu-propsA doc/menu-props.xml - contains "enabledClass"/"disabledClass" this will add these attributes for selectmany_menu, selectone_menuM 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 inAW> 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>.C031Adding 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(). |
