You cannot run a Faces JSP file that contains unbound Faces Client components on the server. You must bind Faces Client components to a client data object to be able to run on server.
This problem is caused by NullPointerExceptions in the internal WDO code. To work around this problem, either replace the null value in the database with a default value or upgrade your server to WAS 6.0. If upgrading, be sure to follow the section in the Migration guide titled, "Migrating JavaServer Faces resources with Faces Client Components."
Note: Faces JSP containing client data created from an empty relational record do not run on WAS 5.1 for the same reason. There is no easy workaround for this problem.
If the target components of a "Set selected object as root in target component" event handler are renamed after the event handler snippet is created, the JavaScript will be incorrect. To work around this problem, delete the snippet and recreate it.
Faces components that implement file upload and download functionality are not supported in portlets. These Faces components include:
- File Upload
- Image, Link and Media Players when bound to a BLOB (or byte[]) data source
When you submit a Faces JSP file after adding a row to a datagrid bound to a relational record list which is two or more levels deep in a datagraph, you get a java.lang.IllegalArgumentException: The feature 'CUSTOMERS_ORDERS' of 'CUSTOMERS' isn't a containment.
This is a limitation in the way Faces client handles updates. In SDO, all relations are contained (containment=true) within the "DatagraphRoot" and each relation references (containment=false) other relations contained within the root. The faces client DiffHandlers always try to add the new objects to the "parent" rather than to the "container".
The workaround for this problem is to create the relational record list to be updated with new rows as a level one relation. For example, if you wish to add a row into an ORDERS table, which is owned by a CUSTOMER, instead of creating a relation CUSTOMER -> ORDERS and then adding a row into ORDERS, you would create a relational record list ORDERS and add a row into ORDERS.
If you have a dataTable nested inside of a dataTable (for example, a property of the row is a collection) that has input components in the column, the data model will not update correctly.
The location of generated tags may be incorrect when you drop data onto a Faces JSP file that is derived from a page template. If the template has more than one content area within the page body, then dropping data from the Page Data View or Data drawer on the Palette will always generate new tags into the first content area. If the desired target was not in that content area, switch to source mode. Then, cut and paste the generated source to the correct location. Make sure all the new tags are selected, including a surrounding h:form tag if one is present, and also ensure that the paste location is somewhere inside a hx:scriptCollector tag in the desired content area.
When working with a project originally developed using WSAD 5.1.2 the user may be prompted to migrate Faces resources in the project. If the user responds YES, the Faces runtime is automatically updated to the latest levels; however, if WDO was used for data access, additional configuration needs to be performed manually:
- Create a new temporary Faces JSP file in the original project. (Click File > New > Faces JSP File. Refer to the on-line help for assistance.)
- Drag a relational record component from the Data drawer on the palette to the page. Choose to reuse existing metadata and select any of the existing WDO .xml files that are listed. This process generates any necessary configuration to continue using WDO in this project.
- Delete the temporary JSP file.
For more information refer to the product Migration Guide.
The validation page of the inputText field may not update correctly when a user has multiple inputText fields on a page. This problem occurs if the inputText fields have different converter sub-tags. For example, if one inputText field is using a convertNumber converter and the other has a convertDateTime converter, the validation page will not refresh correctly when switching between tags. There are two possible workarounds: Switch to source mode and click on the child validation or helper tag (at this point the page will refresh). The other workaround is to close and reopen the JSP.
The DiffHandlers generated for EGL client data have incorrect syntax for referencing nested types. To work around this problem, edit the client-data mediator classes to use the correct syntax. Use a period (.) instead of a dollar sign ($). For example, if you have code such as:
if (_Root instanceof pagehandlers.overdueaccounts$COMPANYNAME)
change it to:if (_Root instanceof pagehandlers.overdueaccounts.COMPANYNAME)
When you create client data that reuses existing SDO/WDO client data, make sure to reuse the WDO/SDO metadata file and the model name. When you create the WDO/SDO from the Page Data view, select "Reuse metadata definition from an existing record or record list." Then, browse and select the metadata file for the SDO you are reusing.
To fix this problem, make sure all JSF and JSF client controls have unique IDs across all the portlets used on the same portal page. Conflicts are possible if the portal page uses unknown portlets with duplicate IDs. It is suggested that you include the JSP name as part of the ID to ensure that the ID is unique.
There is no known workaround for this problem. It is suggested that you minimize the use of labels to avoid cluttering.
There is no workaround. Do not use custom open and close icons in tree view in portal.
You may lose precision with default formatting when plotting a series of close values on the y-axis. This lack of precision can cause values to be repeated. To avoid this problem, choose appropriate custom number formatting and do not use the default.
To work around this problem, increase the size of the graph.
The header and footer for the datagrid are not displayed in the following scenarios:
- When the datagrid is bound to an empty relational list
- When adding items programmatically to the datagrid and the number of items exceeds the height of the datagrid
The Webservice invocation fails when you host the webservice and the client on two different server machines. There is no known workaround, although the Macromedia Web site has posted some solutions for this cross-domain problem. It is suggested that you host both the Webservice server and the Client on the same server.
To remove these warnings from your project, right-click either the javasource folder, your project, or the packages with the warnings. Then, select Source > Organize imports from the context menu.
You may receive this error when you drop a Faces Client component to a page that contains multiple client data on the same page. To work around this problem, switch to the Source View for the JSP and move all the <odc:clientData> tags immediately below the <h:form> tag.
If you drop a tree component to the page or cut and paste the source for the tree component on the page, the <odc:tree> tag may accidentally have a <p> tag as its parent. This will cause the tree component to be rendered incorrectly on the resulting HTML page. To workaround this problem, delete the <p></p> tags surrounding the <odc:tree> tag.
You cannot drop an image file into a tabbed panel from the Thumbnails view or the Project Explorer view. To place an image inside the panel, drag and drop an Image from the HTML Tags drawer of the Palette view, and then select the image file you want to drop.
You may receive broken link warnings after you follow steps in the migration guide for retargetting servers (from WebSphere Application Server V5.1 to V6.0) for projects containing Faces Client components. If you receive these warnings or if your pages do not display correctly when you run them on the WebSphere Application Server v6.0, close your Web project and then reopen it.
The rich text editor behaves as if it is read-only when it is run on server using the internal browser. This problem might occur when the page is loaded initially or after submitting a page to the server. Use an external browser to work around this problem.
This problem results from using the Faces prefix in the URL to Faces pages and relative paths to page resources (css and images). You can work around this problem in two ways:
1) Use fully qualified path names to page resouces.
2) Use URLs to Faces pages that have the .faces extension and not the faces/ prefix. Faces pages must be handled by the Faces servlet. In the project web.xml file, two mappings are added to this faces servlet by default.
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping><servlet-mapping>
Neither the Faces folder nor the file with a Faces extension actually exist. You just need to make them part of the Faces page URL. To address page1.jsp, you can use /faces/page1.jsp or /page1.faces. Both of these can be configured (for example, you can use .page as the extension).
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
When a datagrid is bound to client data created from a relational record list with only one column, the binding generated is incorrect. For example: #{pc_Index1.surveys[0].NAME} is generated instead of the correct binding {pc_Index1.surveys}. The workaround is to edit the JSP source manually to remove the extra index and the column name (as shown in the example above).
This problem occurs because the workspace building operation is not complete. To remove all the errors, go to the Project menu and select Clean.... Then, choose to clean the FacesClientTutorial project. Once the clean is done and the rebuiling operation finishes, all the errors should go away.
Some early versions of the help topic, "Migrating JavaServer Faces resources with Faces Client Components," may be missing information on the following items:
If you are missing this information, refer to the the HTML version of the Migration Guide, which is located at root of the first CD or under disk1/migrate.html of the electronic images.
- Two problems that may occur when changing the target server of a project containing Faces Client Components from WebSphere Application Server V5.1 to V6.0:
- Client Data mediator classes that have already been generated will no longer compile.
- Tree View Faces Client Components bound to WDOs fail to run on server after changing the project's target server to WebSphere Application Server V6.0.
- Information regarding working in the Linux platform or a non-English locale.
There is a problem where JavaServer Face (JSF) pages appear to lose content on submit. This could have to do with how state is maintained for the page and how requests are handled for page resources (e.g. css and image files) that are specified with a relative path (e.g. theme/stylesheet.css). To work around this problem URLs to JSF pages should use the .faces extension option. For example the URL to the JSF page myPage.jsp would be /MyWebApp/myPage.faces. This extension is defined in the project web.xml file. Another option is to elect to save state in the client
Return to the main readme file