Partial Page Rendering (PPR)

Last Updated 2-Dec-2003

General Description

Partial Page Rendering (PPR) is a technology provided by the UIX (Cabo) team that allows a portion of a page to be redrawn rather than reloading the entire page. Before PPR, redraw of individual page elements was only available through custom Javascript code, which is generally discouraged in BLAF applications because of cross-browser incompatibility and reliability.

PPR offers significant benefits to users. When implemented correctly, PPR both improves application performance and provides more direct feedback when users perform actions. This guideline includes the following sections:

General Principles
Contexts For Use of PPR
Page Elements That Do Not Change During PPR
Page Elements That May Change During PPR
Contexts in Which PPR Should Not Be Used
Contexts in Which PPR is Disabled
Mandatory Use of the "Go" Button
PPR and Browser History
PPR vs. Custom Javascript

Note: PPR is automatically disabled when pages are loaded by browsers that do not support PPR. At this time, PPR is only supported by IE 5.5 and higher, Mozilla and Netscape 7.

Technical Note: At this time time, Cabo does not yet provide PPR support for all components listed in this guideline.

Guideline Attributes

Spec Version # - 3.1
Spec Contributors - Betsy Beier, Ivy Leung, Mervyn Dennehy, Lisa Rinderknecht
UI Models - all models
Example Products - all products
Related Guidelines - Tables; Search Templates, Hide/Show Component; Locator Element: Record and Page Navigation; ; LOV Template; Flexfields; HGrid; Tree; Headers

Interaction and Usage Specifications

General Principles

PPR is intended only for partial rendering of pages that do not require extensive back-end processing. Do not use PPR when most of a page's content needs to be redrawn, or time-consuming queries are needed to generate/refresh the content.
Unlike full page reloads, PPR does not force focus to the top of the page, and thus provides a minimum of distraction from the task at hand.
With PPR, the "Go" button can be omitted from choice lists and radio groups in many contexts. See Use of the "Go" Button below for a list of exceptions.
PPR is never used when navigating to a page with a different title. The Go button is also required in this case.
The Browser History feature does not track PPR. See PPR and Browser History below for more details.
PPR is disabled if a page is loaded by a browser which does not support PPR.
When the user performs an action that initiates a PPR update, there will be an event block period for a preset time while the update is being performed:
- During this period, the wait cursor is displayed, and the user will not be able to perform any other actions on the page until the event block is lifted.
- There will be a time out for the event block if the PPR update is not completed by the number of seconds specified: In this case, the event block will be cleared, the page will remain unchanged, and the user will be able to perform other actions on the page.
- UIX may be able to provide the time out period as a parameter of "n" seconds/minutes, so that teams can set up the appropriate estimated time for different PPR fields.
- The event block period is necessary because a PPR event can change the state of the page, so that a subsequent click or key entry might target a control that is about to have its state changed (maybe the onClick handler will change, maybe the control will go away altogether).
If an unexpected error occurs during a PPR event, a Javascript HTTP error message should be displayed. Examples of unexpected errors include, server failure to respond, or timeout for event blocking. BLAF messaging cannot be used in these conditions, as the user may lose data if the application attempts to do so. Using Javascript is the "safest" approach.
Oracle internal developers can read an introduction to PPR at http://bali.us.oracle.com/cabo/docs/ppr-architecture.html

Contexts For Use of PPR

PPR has three general uses:

Re-Render Data: The same fields are redrawn but their data is updated. Examples include the Refresh Data action button, or recalculate totals in a table.
Re-render Dependent Fields: Fields may be added, removed, or change sequence, and data may be updated. Examples include the Country choice list, which may display different address fields, and toggling between Simple and Advanced Search.
Hide/Show Content: Both fields and data toggle in and out of view.

The following table shows specific contexts and examples for each of these general usages, as well as the effect of disabling PPR:

PPR Usage	Context	PPR Initiated By	Related Guidelines	PPR Notes	If PPR Is Disabled
Re-render data (same fields are redrawn but data is updated)	Refresh field(s) with latest data	Functional icon; Action button		The Refresh Data button updates field or table content. The Refresh Date functional icon updates the date in a field	The full page is reloaded
	Recalculate values in table or form	On exit of value field	Tables	The "Recalculate" button is no longer required.	The "Recalculate" button is displayed, and the full page is reloaded
	Sort data in a table	Table column header	Table		The full page is reloaded
	Record navigation in a table	Choice list and Link	Record Navigation		The full page is reloaded
	Auto-populate dependent fields in a form or table	Choice list; LOV; Action button		The "Go" button is no longer required with the choice list in this context. The LOV uses validation on exit of field.	The "Go" button is displayed, and the full page is reloaded
	Update aliases in field	Key flexfield	Flexfields	The key flex field icon is still required, but validation occurs on exit of field. In a banking application, if a user enters the text "checking", the flexfield can automatically update with the user's checking account number.	The key flex field icon is displayed, and the full page is reloaded
	Progress indicators in processing pages	Processing page	Processing pages	Progress indicators may be either text or graphical or both. Note that certain processing options may also require addition of new fields.	The full page is reloaded
Re-render dependent fields (fields may be added, removed, or change sequence, and data may be updated)	Selection of data in "controlling" field ***	Choice list (without "Go" button); LOV; Key flexfields; Radio group (without "Go" button)	Common Formats; Content Layout; Flexfields (Contextual)	The Country choice list displays different address fields depending on country selection. In an HR application, selecting the job title of "Director" could display fields for budget allocation or a list of job responsibilities. In a catalog, selecting standard or enhanced models of a product would display different options and prices.	The "Go" button is displayed next to choice lists and radio groups, and the full page is reloaded
	Actions on rows in table or HGrid	Action buttons; Functional icons	Tables; HGrid	Examples include Add and Insert Row, as well as Delete, as long as user does not need to confirm deletion	The full page is reloaded
	Toggle form functionality	Action button; Link	Search Templates	Examples include Simple and Advanced Search sections	The full page is reloaded
	Master/detail view updates on new selection (specifically for Master/Detail templates)	Icon; Tree node	Master/Detail Templates	When user selects Master record node in tree or icon in upper table, the Details region/table below is redrawn.	The full page is reloaded
	Toggle subtab content	Subtab on master/detail template	Master/Detail Templates		The full page is reloaded
	Processing pages that list progress steps	Processing page	Processing pages	Processing pages may include text or graphical progress indicators along with new fields for each step accomplished.	The full page is reloaded
Hide/Show content (may include both fields and data)	Hide/Show a section of the page	Link; Icon	Hide/Show Component; Headers	Hide/Show section below headers; Hide/Show basic/more search criteria	The full page is reloaded
	Hide/Show row content	Icon; Link	Tables	Hides/shows additional details for selected row
	Hide/Show cell content	Icon; Link	Tables	Hides/shows additional details for selected cell
	Hide/Show more menu content	Icon	Tabs/Navigation: Side Navigation	Hides/shows additional menu options in Side Navigation
	Expand/Collapse level of hierarchy	Icon	HGrid; Tree	Selecting expand/collapse icon in tree or HGrid reveals/hides child nodes
	Focus on new root in HGrid/Restore focus to parent	Icon; HGrid breadcrumb links	HGrid

*** Note: Depending on context, selection in the controlling field may display the same or different fields. For example, the Country field selection usually changes the sequence and labels of address fields, but Name fields may remain unchanged.

The following images illustrate PPR in several contexts:

Page Elements That Do Not Change During PPR

Some page elements are always associated with a page, regardless of the content displayed on the page.

As a general rule of thumb, elements above the page title (except message boxes) remain constant and do not change position, whereas elements below the Ski remain constant but may move up or down the page to accommodate changes to page content. The following elements never change when PPR is initiated:

Branding
Global buttons
Tabs, Horizontal Navigation, SubTabs
Locator elements: Breadcrumbs, Train, Next/Back Locator
Quick links
Page titles (first level header)
Ski
Page footer
Separator lines between the Tabs and Page Title

In most cases the following elements will also not change, other than moving up or down the page to accommodate changed elements. Nevertheless, in certain cases actions on the page may require them to be redrawn:

Side Navigation, unless it contains a Hide/Show control.
Subtabs
Contextual information
Page-level action/navigation buttons
Page-level Instruction text
Page-level Page stamps
Page-level Key Notation

Page Elements That May Change During PPR

Most other areas of page content may be individually added, changed, or removed during PPR, including:

Section and table titles (subheaders)
Section-level elements associated with a section title:
- Hide/Show link
- Instruction text
- Key notation
- Page stamps
Label/data layout, including Action/Nav buttons, choice lists, and links.
Tables and table elements
HGrids
Trees
Graphs
Content containers
Tips and Hints
Icons

Contexts In Which PPR Should Not Be Used

When PPR is implemented correctly, it significantly improves application performance. When performance improvement is not possible with PPR, it should not be implemented, thus avoiding unnecessary code bloat.

PPR should not be invoked in the following contexts:

When navigating to another page (with a different title).
When response times may be long, such as:
- Database queries or database maintenance operations
- Processes that demand significant middle-tier processing
When multiple sections of the page need to be redrawn, such as:
- Action or choices that affect more than half the content of the page.
- Inline messaging, which features a message box at the top of the page, and may insert inline messages below multiple fields.

Contexts in Which PPR is Disabled

PPR is disabled in browsers which do not support PPR. When disabled, both display and behavior of UI elements may change:

Action buttons, such as the "Go" button, are always displayed together with choice lists and radio groups.
Actions usually initiate a reload of the entire page. The only exception to this rule is when applications use Javascript to check that required fields have been filled out, and to validate the format of data entered into fields. Note that this option is not recommended. For more information on field validation, see the Messaging Templates guideline.

Mandatory Use of the "Go" Button

Before PPR, choice lists and radio buttons with dependent fields required a "Go" button for users to activate their selection. With PPR, actions can be initiated on field exit, so the "Go" button can often be omitted. However, in the following contexts, the "Go" button MUST always be retained, even though these contexts may only require redraw of the current page:

Search: All types of search, including Views, (except when a Search button is used instead) because search depends on back-end processing, which may be extensive, and require the user to wait. If users explicitly click a button to initiate the search, they will be less likely to be surprised by the wait time. For details on different types of search, see the Search Templates guideline.
Actions List: This list typically includes a mix of choices, some of which may navigate to another page, and some which may only redraw the current page. The Go button is required to confirm any choice to navigate to another page, and there is no way to know beforehand which action the user will choose, so the Go button is displayed regardless of the choice made in the list.
Table Filters: The table filter mechanism depends on back-end processing (like Search). Requiring users to click a 'Go' button will reduce confusion caused by the resulting wait time.

PPR and Browser History

The Browser History feature tracks the pages and page anchors loaded into the browser, but does not track PPR. When users click the browser Back or Next buttons, they leave the initial page or anchor and go to the previous or next pages/anchors in the History stack. If they return to the initial page, it will be reloaded in its initial state, and any PPR-related display changes are lost. The following example illustrates the issue:

A user navigates from an Overview page to an object list page containing a table, and then navigates through forty sets of records. Each of those record sets is displayed via PPR. If the user then clicks the browser Back button, the initial Overview page is reloaded. If the user then clicks the browser Forward button, the object list page is reloaded with the first record set, and the browser Forward button is disabled. The user must then navigate through the records again to return to the fortieth record set.

Note: In this example, the loss of record navigation History can be offset by use of a record locator with a choice list, which speeds up navigation through large record sets. See the Record and Page Navigation guideline for details.

This partial loss of browser History is not optimal, but it is offset by PPR's benefits. PPR not only improves application performance, but it also improves user experience of the application -- unlike full page reloads, PPR does not does not "flash" and force the user to the top of the page, and thus provides a minimum of distraction from the task at hand.

PPR vs. Custom Javascript

Before PPR, redraw of individual page elements was only available through custom Javascript code. Use of custom Javascript to redraw portions of the page should be avoided for the following reasons:

Reliability of Cross-browser Code: Both PPR and Javascript code must be customized for different types and releases of browsers. However, PPR code is developed and tested centrally, providing greater reliability. Custom Javascript code can crash browsers.
Coding Model: Because custom Javascript is not centrally supported, variances in scripting between development teams cause inconsistency in user experience, as well as requiring duplication of development effort.
Performance: The Javascript approach typically requires larger file sizes to accommodate UI variables, resulting in slower page load.
Error Handling: User error on a Javascript-enabled page can easily result in display of multiple alert windows with little indication of the fields generating the errors. This can be extremely frustrating to users, and can lead to failure to perform a task. Standard BLAF error messages can be displayed inline with pointers to related fields, or on more informative message pages.