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:



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

Contexts For Use of PPR

PPR has three general uses:
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:
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:

Page Elements That May Change During PPR

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

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:

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:

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:

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:

Open/Closed Issues