JavaServer Faces and ODC tools Release Notes

© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.

Release notes

1.0 Limitations
   1.1 Faces Client Components and Client Data are Deprecated
   1.2 Migrating pre-V7 JSF applications
   1.3 Tree modification when moving from WDO to SDO
   1.4 hx:commandExButton is now rendering image correctly
2.0 Known problems and workarounds
   2.1 The jspPanel tag attributes style and styleClass are no longer available
   2.2 Inaccurate warning dialog appears during project imports
   2.3 Multiple Client Data models per page
   2.4 Building Portlets that use Client Data in V7.0+
   2.5 Tabbed Panel with Height as Percentage
   2.6 Tabbed Panel Tabs in Strict Mode
   2.7 hx:convertDateTime does not work correctly with Arabic calendars
   2.8 When targeting WebSphere runtime, ensure WebSphere project facet is selected
   2.9 JWL DataTable column alignment is not correct when using loose.dtd and percentage-width columns
   2.10 In an hx:panelDialog, "relative" positioning may not work if the base tag used for positioning is scrolled
   2.11 A data table with row selection enabled cannot be put in a panel that is AJAX enabled
   2.12 ajaxExternalRequest may not work correctly in IE if the id of the panel in the target page doesn't match the id of the panel in the source page
   2.13 The inProgresss attribute for hx:ajaxRefreshRequest and other AJAX-tags does not work
   2.14 hxinputHelperTypeahead does not correctly handle looking up values with space characters, percent symbols and ampersands in them
   2.15 hx:panelDialog may be positioned incorrectly in Firefox version 1.5.0.8 or later
   2.16 hx:pagerDeluxe does not render correctly if the styleClass is not "pagerDeluxe"

1.0 Limitations

1.1 Faces Client Components and Client Data are Deprecated

The following have been deprecated and are not recommended for use:

The Tree <odc:tree> and Chart <odc:graphDraw> have been enabled to use Server Data.

1.2 Migrating pre-V7 JSF applications

If you import a pre-V7 JSF application without migrating the JSF JARS and continue to develop the application, tags that are new in V7 will not be included in the project JARs and will not be available at runtime.  Ensure that you migrate pre-V7 JARS.

1.3 Tree modification when moving from WDO to SDO

The Tree control <odc:treeNodeAttr> tag uses different values for its className attribute when bound to SDO data versus WDO data. After migrating a project from a server that uses WDO (such as WebSphere® Application Server 5.1) to one that uses SDO (such as WebSphere Application Server 6.1), the easiest way to fix this is to delete and recreate any Tree controls. 

1.4 hx:commandExButton is now rendering image correctly

In v6.0, if an <hx:commandExButton> had the type set to Submit and it had a label and only single background image (for example value="submit" image="button.gif"), only the image was rendered (not the image and the label). This problem is fixed in v7.0. The fix means that buttons that have both a label and a single background image will render differently when using v7.0 than they did with v6.0.

Similarly, if an <hx:commandExButton> had the type set to Reset and it had a single background image (or a background image and a label), only the image would be rendered and the button was treated as a submit button (the type of the button was ignored). This problem is fixed in v7.0. The fix means that buttons marked with the type set to Reset will now reset the page instead of submitting it.

2.0 Known problems and workarounds

2.1 The jspPanel tag attributes style and styleClass are no longer available

The <jspPanel> tag attributes style and styleClass are no longer available. The attributes are not used for rendering the JSP panel component.

If you import a JSF application created in a previous version of this product, the <jspPanel> tags will display errors. To resolve the errors, remove the style and styleClass attributes from all <jspPanel> tags in the project by editing the JSP source in the Source view.

2.2 Inaccurate warning dialog appears during project imports

If you import projects into your workspace that were created using a previous version of the product, you may see a dialog pop up stating that Faces support was installed but no target runtime was selected for the project. In some cases this warning is not accurate and a runtime will be correctly defined after the migration process completes.  To check if a runtime is set right-click Project > Properties and select Targeted Runtimes. If a checkbox appears next to any defined servers then no further action is required, otherwise select one of the servers.

2.3 Multiple Client Data models per page

Note: this workaround is not required where client data models are created from the same page data node or page data nodes of the same name.

In v7.0, when there are multiple client data models on the page, created from the same bean classes, a second ecore and emap file will be erroneously created for the second model upon generation (or regeneration). In accordance with the migration guide, when migrating client data projects, the client data models should be regenerated so this can impact migrated projects with pages containing more than one client data model. A simple scenario is as follows:

  1. Create two page data based on the java.util.Date bean, for example myDate1 and myDate2.
  2. For each of the page data, create a client Data model of the same name in the order: myDate1 then myDate2.

Workaround: To get a page working with both models, delete myDate2.ecore and myDate2.emap from the com.ibm.dynwdo4jsmediators package and the corresponding entries in the OdysseyBrowserFramework.properties file.

2.4 Building Portlets that use Client Data in V7.0+

Client Data outputs a large amount of JavaScript to a page. In previous releases the JavaScript was not encoded. This meant that if you were using Client Data in multiple portlets, using the same page data source, the JavaScript output to the page would be the same for all portlets.

This behavior, where two portlets bind to Client Data, could appear to bind to the same Client Data object (as the second section of JavaScript will overwrite the first). This in turn allows the two portlets to interact, where a change in one would be represented in both.

This is problematic if you want to have multiple portlets on a page that use Client Data that work independently of each other. JavaScript errors occur when you have two portlets using Client Data on the same page with different Page Data sources. This can also cause one of the portlets not to render.

To fix these problems and allow Client Data Portlets to run over WSRP, the Client Data JavaScript variables must be encoded, so that they are unique to each portlet. This allows the Client Data JavaScript sections to work independently of each other.

In V7.0, all client data will be encoded.

If you want to share Client Data between portlets on a page, you will need to update web.xml with the following context parameters:

    <context-param>
        <param-name>com.ibm.faces.ENCODE_DATA</param-name>
        <param-value>false</param-value>
        <description></description>
    </context-param>

By setting <param-value> to false, you are removing the Client Data encoding.

Using the Encode_Data Param and its effect on the Chart and Data Tree components using Page Data

The Chart and Data Tree use page data by putting an XML data object on the page. Page Data for the Chart and Data Tree is very closely linked to Client Data for those components. By default this data is encoded. If you set the <context-param> shown below in your web.xml file, which is normally used to remove Client Data encoding, it will also remove Page Data encoding for the Chart and Data Tree. No other components using page data will be affected. Leaving the page data without encoding, means having two portlets on a page, where both contain a chart or a Data Tree, may cause problems. These errors include JavaScript errors and/or one of the portlets not displaying properly.

As with Client Data to encode this data, allowing two portlets on a page to run independently of each other and to enable WSRP support, you will need to remove the following <context-param> from web.xml or set the <param-value> to true:

    <context-param>
        <param-name>com.ibm.faces.ENCODE_DATA</param-name>
        <param-value>true</param-value>
        <description></description>
    </context-param> 

2.5 Tabbed Panel with Height as Percentage

This is placed at the top of the page:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This causes Web browsers to go into standards mode. In standard mode, the HTML and body elements snap to their contents rather than filling the window as occurs in quirks mode (the default HTML mode).

When a tabbed panel is placed on the page on its own with its height set to a percentage, this will cause display issues with the pane height.

To fix this, place the tabbed panel in a container that has a height set or change the doctype at the top of the page to:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

2.6 Tabbed Panel Tabs in Strict Mode

There are display problems with tabs in standards mode when the doctype is set to:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This is rectified by changing the doctype to:

     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

2.7 hx:convertDateTime does not work correctly with Arabic calendars

The <hx:convertDateTime> tag does not generate correct JavaScript when the calendar type is set to Arabic.  As a result, client-side validation, input prompting, date picker helper, and mini calendar do not work correctly. When the generated JavaScript is initialized, an error is displayed (or the component does not work correctly).

Workaround: Do not turn on client side validation or prompting. Do not turn on the date picker helper if the Arabic calendar is used with the converter.

2.8 When targeting WebSphere® runtime, ensure WebSphere project facet is selected

When targeting a WebSphere® server runtime, ensure that the WebSphere Web (Co-existence) project facet is selected for your Web project. 

Workaround: Select the facet on the second page of the Dynamic Web Project wizard when creating the project, or though the Project Facets page of the project Properties dialog if the project already exists.  When creating a Web project targeted to a WebSphere server, if you select "Faces Project" or "Dynamic Web Project with XDoclet" from the Configurations drop-down list on the first page of the project wizard, the WebSphere Web (Co-existence) facet will not be automatically selected.  You can continue to the next page of the wizard to select this facet.  If you select "<custom>" from the Configurations list, the facet will be properly selected when targeting a WebSphere runtime.

2.9 JWL DataTable column alignment is not correct when using loose.dtd and percentage-width columns

When using an <hx:columnEx> within an <hx:dataTableEx> and vertical scrolling is enabled (scrollSize is set), if one or more of the columns in the table has its width set to be a percentage-based width, in the rendered table, the column headers and column contents may not be aligned with each other if the doctype of the page is interpreted by the browser as being W3C standard (versus W3C transitional). For example, this will happen if the doctype includes a loose.dtd declaration.
Workaround: Make the column widths fixed (not percentage based) or make sure the doctype resolves to a transitional doctype (for example remove the loose.dtd declaration).

2.10 In an hx:panelDialog, "relative" positioning may not work if the base tag used for positioning is scrolled

In an <hx:panelDialog>, if the positioning (either horizontal or vertical) is set to relative and the tag used as the base for the positioning (the tag the dialog is positioned relative to) is in a page that is scrolled such that the tag is on display and the page is not scrolled to the top, when the dialog is displayed, it may be positioned incorrectly (usually positioned too far to the top or too far to the left).

Workaround: If relative positioning is required, ensure that the base tag is near the top of the page.  Alternatively, use one of the other types of positioning.

2.11 A data table with row selection enabled cannot be put in a panel that is AJAX enabled

If a data table (either <h:dataTable> or <hx:dataTableEx>) is in a panel that is AJAX enabled and is row selection enabled (<hx:inputRowSelect> is included in the table), the checkboxes in the selection column will not work correctly when the table is re-fetched via AJAX. It will work correctly the first time (only) that is rendered.

Workaround: There is currently no workaround for this problem. Do not put the table in an AJAX-enabled panel.

2.12 ajaxExternalRequest may not work correctly in IE if the id of the panel in the target page doesn't match the id of the panel in the source page

<hx:ajaxExternalRequest> may not work correctly in Internet Explorer (IE) if the source attribute is used to specify the ID of the panel to be retrieved in the target page differs from the ID of the panel the <hx:ajaxExternalRequest> is attached to in the source page. For example, <hx:panel id="panel1"><hx:ajaxExternalRequest  source="panel999" /><hx:panel>. The problem only occurs in IE and only occurs if the target panel is a grid, box, or layout (a panel that renders as an HTML table).

Workaround: Make sure the IDs are the same or wrap the target panel in a panelGroup.

2.13 The inProgresss attribute for hx:ajaxRefreshRequest and other AJAX-tags does not work

The inProgresss attribute for <hx:ajaxRefreshRequest>, <hx:ajaxRefreshSubmit>, <hx:ajaxExternalRequest>, and <hx:inputHelperTypeahead> does not work. Setting a value on this attribute has no effect. To ensure compatibility with future releases, do not set the value.

2.14 hxinputHelperTypeahead does not correctly handle looking up values with space characters, percent symbols and ampersands in them

When <hx:inputHelperTypeahead> is attached to an input field, if a space character and/or punctuation characters such as ampersand and percent are entered into the field, the list of suggestions that are constructed will not include any "matches" that include these characters. For example, if a user types %, no matches will be returned even if there are words in the "dictionary" in use that start with %.

2.15 hx:panelDialog may be positioned incorrectly in Firefox version 1.5.0.8 or later

A change in the behavior of some HTML DOM attributes beginning in Firefox version 1.5.0.8 may result in a panelDialog not being positioned correctly when rendered in Firefox. The problem most commonly occurs when a dialog is relatively positioned, but can occur in other cases where the size of the body content is "less than" the height of the browser window (that is, when the page does not vertically scroll).

Workaround: Adding content to the body (even white space such as a <div> with the height set) such that the vertical scroll bar is always on in the page may workaround the problem (this depends on the exact dimensions of the browser window and content).

2.16 hx:pagerDeluxe does not render correctly if the styleClass is not "pagerDeluxe"

<hx:pagerDeluxe> does not render the correct HTML markup if the styleClass is set to something other than the default class pagerDeluxe. The buttons in the pager will always be rendered with class names that use the default class name in them.

Workaround: