| Oracle® Application Development Framework Developer's Guide 10g (10.1.3.1.0) Part Number B28967-01 |
|
|
View PDF |
| Oracle® Application Development Framework Developer's Guide 10g (10.1.3.1.0) Part Number B28967-01 |
|
|
View PDF |
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. The XML standard offers many benefits such as validating against a document type definition, and parsing to create documentation or audit reports.
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.
Note that javax.faces.STATE_SAVING_METHOD must be set to server for ADF Telnet applications because the Industrial Telnet Server does not currently support saving state on the client.
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 & in JSP documents (.jspx). For example, in this code snippet:
<af:commandButton textAndAccessKey="&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".
