Hints and tips for the Page Builder theme and widgets
Some hints and tips for working with the Page Builder theme and widgets.
Hints and tips for working with the Page Builder theme
When you work with the Page Builder theme, observe the following hints and tips:
- Pages with the Page Builder theme do not support composite applications.
- Pages with the Page Builder theme do not support Portal business process integration.
- Client side mode imposes some limits on the use of friendly URLs. In client side mode friendly names shown in the browser URL field do not always and necessarily reflect the page that is shown in the browser. For example, when a user changes to a different portal page in client side mode, the portal page changes, but the friendly name in the browser URL field remains the same, as the user request sent to the server is not for a complete refresh of the page. Only a full page refresh changes the friendly name in the browser URL field. Users can still insert a friendly name in the browser URL address field to access a particular page. That page is then rendered by a request to the server and a subsequent full page refresh.
Hints and tips for working with widgets
When you work with iWidgets, observe the following implications, hints, and tips:
- WebSphere supports iWidgets that comply with the iWidget specification Version 2.1. More details about this specification are available under the link to the iWidget Specification v2.1 given below. The portal iWidget registration process validates the iWidget definition XML file against this specification and rejects widgets that do not comply with it.
- As the parsed iWidget definition is persisted in the portal database, this information can become outdated if the iWidget definition file is updated. You can refresh the iWidget definition data persisted in the portal database. To do this, use the configuration task refresh-iwidget-definitions. To refresh the information, you can run the task manually or schedule the task by using the portal task scheduler.
- Portal access control guards the rendering of iWidgets on portal pages and the read/write access to iWidget metadata, such as preferences. Portal access control does not guard the direct HTTP based access to the iWidget files. If this is a concern, you need to provide such access control by the infrastructure that serves the iWidget files. For example, use J2EE authorization for iWidgets that you deploy as J2EE applications.
- When you register iWidgets located on external servers, be aware of the following additional implications and restrictions:
- The Ajax Proxy needs to be opened to allow accessing the iWidget files on the external servers.
- When rendering the iWidget, the external server needs to be accessible by the portal, as the portal loads the widget files from the external server.
Parent Design a site using Page Builder themes and skins
Previous
iWidget Specification V 2.1: public.dhe.ibm.com/software/dw/lotus/mashups/developer/iwidget-spec-v2.1.pdf
|
|
| Apr 1, 2011 1:26:17 PM
|
|
|
|
});
|