Skip Headers

Oracle® Application Development Framework Developer's Guide 10g Release 3 (10.1.3) B25386-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 4.6 Best Practices for ADF Faces

Consider the following best practices when developing with ADF Faces:

- While both JSP documents (`.jspx`) and JSP pages (`.jsp`) can be used, Oracle recommends working with JSP documents (`.jspx`) when using ADF Faces components in your JSF pages because JSP documents are well-formed XML documents.

- Use token-based client-side state saving instead of server-side state saving by setting the value of `javax.faces.STATE_SAVING_METHOD` in `web.xml` to `client` (which matches the default server-side behavior that will be provided in JSF 1.2).

  While server-side state saving can provide somewhat better performance, client-side state saving is recommended as it provides better support for failover and the back button, and for displaying multiple windows simultaneously. Token-based client-side state saving results in better server performance because CPU and I/O consumption is lower.

- Remove or disable debug features to improve the performance of deployed applications:

  - In `web.xml`, disable `oracle.adf.view.faces.CHECK_FILE_MODIFICATION`. By default, this parameter is `false`. If it is set to `true`, ADF Faces automatically checks the modification date of your JSPs, and discards saved state when they change. For testing and debugging in JDeveloper's embedded OC4J, you don't need to explicitly set this parameter to `true` because ADF Faces automatically detects the embedded OC4J and runs with the file modification checks enabled. But when you deploy the application, you should set the parameter to `false`.

    For testing and debugging in JDeveloper's embedded OC4J, you don't need to explicitly set this parameter to `true` because ADF Faces automatically detects the embedded OC4J and runs with the file modification checks enabled.

  - In `web.xml`, disable `oracle.adf.view.faces.DEBUG_JAVASCRIPT`. The default value of this parameter is `false`. This means that by default, ADF Faces obfuscates JavaScript and removes comments and whitespace to reduce the size of the JavaScript download to the client. During application development, you might set the parameter to `true` (to turn off obfuscation) so that you can debug JavaScript easier, but when you deploy the application, you should set the parameter to `false`.

  - In `adf-faces-config.xml`, set `<debug-output>` to `false`. ADF Faces enhances debugging output when `<debug-output>` is `true`, by adding automatic indenting and extra comments, and detecting for malformed markup problems, unbalanced elements, and common HTML errors. The enhanced debug output is not necessary in deployed applications.

- ADF Faces input components provide support for automatic form submission via the `autoSubmit` attribute. When the `autoSubmit` attribute is set to `true`, and an appropriate action takes place (such as a value change), the input component automatically submits the form it is enclosed in through a partial page submit. Thus you can update a portion of a page without having to redraw the entire page, which is known as partial page rendering. For information about using partial page rendering, see Section 11.4, "Enabling Partial Page Rendering".

- ADF Faces performs client-side and server-side validation upon an auto submit execution. But if both `autoSubmit` and `immediate` attributes on ADF Faces input components are set to `true`, then ADF Faces doesn't perform client-side validation.

- When laying out ADF Faces input components inside `panelLabelAndMessage` components, you must set the `simple` attributes on the input components to `true`. For accessibility purposes, set the `for` attribute on `panelLabelAndMessage` to the first input component. For proper alignment, place multiple `panelLabelAndMessage` components in a `panelForm`.

- Although ADF Faces ignores label and message attributes on "simple" input components, you must set the `label` attribute on a "simple" component in this version of ADF Faces for component-generated error messages to display correctly.

- If both `styleClass` and `styleUsage` attributes are set on a component, `styleClass` has precedence over `styleUsage`.

- ADF Faces provides three levels of page accessibility support, which is configured in `adf-faces-config.xml` using the `<accessibility-mode>` element. The acceptable values for `<accessibility-mode>` are:

  - `default`: By default ADF Faces generates HTML code that is accessible to disabled users.

  - `screenReader`: ADF Faces generates HTML code that is optimized for the use of screen readers. The `screenReader` mode facilitates disabled users, but it may degrade the output for regular users. For example, access keys are disabled in screen reader mode.

  - `inaccessible`: ADF Faces removes all code that does not affect sighted users. This optimization reduces the size of the generated HTML. The application, however, is no longer accessible to disabled users.

- Images that are automatically generated by ADF Faces components have built-in descriptions that can be read by screen readers or nonvisual browsers. For images generated from user-supplied icons and images, make sure you set the `shortDesc` or `searchDesc` attribute. Those attributes transform into HTML `alt` attributes. For images produced by certain ADF Faces components such as `menuTabs` and `menuButtons`, make sure you set the `text` or `icon` attribute on `commandMenuItem` because ADF Faces uses those values to generate text that describes the menu name as well as its state.

  Similarly for `table` and `outputText` components, set the `summary` and `description` attribute, respectively, for user agents rendering to nonvisual media. If you use frames, provide links to alternative pages without frames using the `alternateContent` facet on `frameBorderLayout`. Within each frame set the `shortDesc` and `longDescURL` attributes.

- Specify an access key for input, command, and go components such as `inputText`, `commandButton`, and `goLink`.

  - Typically, you use the component's `accessKey` attribute to set a keyboard character. For command and go components, the character specified by the attribute must exist in the `text` attribute of the component instance. If it does not exist, ADF Faces does not display the visual indication that the component has an access key

  - You can also use `labelAndAccessKey` on input components, or `textAndAccessKey` on command and go components. Those attributes let you set the `label` or `text` value, and an access key for the component at the same time. The conventional ampersand notation to use is `&amp;` in JSP documents (`.jspx`). For example, in this code snippet:

        <af:commandButton textAndAccessKey="&amp;Home"/>

    ... the button text is `Home` and the access key is `H`, the letter that is immediately after the ampersand character.

  - Using access keys on `goButton` and `goLink` components may immediately activate them in some browsers. Depending on the browser, if the same access key is assigned to two or more go components on a page, the browser may activate the first component instead of cycling among the components that are accessed by the same key.

  - If you use a space as the access key, you need to provide a way to tell the user that Alt+Space or Alt+Spacebar is the access key because there is no good way to present a blank or space visually in the component's label or textual label. For example, you could provide some text in a component tooltip using the `shortDesc` attribute.

  - Access keys are not displayed if the accessibility mode is set to screen reader mode.

- Enable application view caching by setting the value of `oracle.adf.view.faces.USE_APPLICATION_VIEW_CACHE` in `web.xml` to `true`.

  When application view caching is enabled, the first time a page is viewed by any user, ADF Faces caches the initial page state at an application level. Subsequently, all users can reuse the page's cached state coming and going, significantly improving application performance.

  While application view caching can improve a deployed application's performance, it is difficult to use during development and there are some coding issues that should be considered. For more detailed information about using application view caching, see "Configuring ADF Faces for Performance" in the "Configuring ADF Faces" section of the ADF Faces Developer's Guide.

- For ADF Faces deployment best practices, see Chapter 22, "Deploying ADF Applications".

- Increase throughput and shorten response times by caching content with the ADF Faces Cache tag library. Caching stores all or parts of a web page in memory for use in future responses. It significantly reduces response time to client requests by reusing cached content for future requests without executing the code that created it. For more information, see Chapter 15, "Optimizing Application Performance with Caching".