Form Layout Usage Guideline Bookmark this Guideline Printable Page


RCUI Document Version 5.0.1 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated 09-Feb-2011

The Form Layout component organizes read-only or editable fields, allowing users to view and modify them quickly.

Guideline Contents

Note: Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.

Related Guidelines

Guideline Section For Information About
Standard Web Widgets All Basic components for use in form layouts, including: Checkbox, Select Choice, Input File, List Box, Input/Output Text, SelectRadio, Spinbox.
Tables All Alternative method to view and edit object details.
Train All Alternative method (guided process) to view and edit object details.
Common Formats All Guidance on use of symbols and other elements in form layouts.

Related ADF Elements

Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for the ADF elements related to this component:

ADF Element Notes
af:panelFormLayout Lays out controls and nested layouts in a form.
af:group Groups related controls.
af:panelGroupLayout Lays out controls in a child group.
af:panelLabelAndMessage Single prompt/data pair layout.
af:separator Separator line between groups.

General Principles Bookmark this Heading Return to Top

Purpose:

The Form Layout component presents data in an organized manner, allowing users to view and modify it quickly.

Description:

  • The Form Layout component organizes FusionFX components on a page or in a dialog box. The components may be read-only or editable.
  • Unlike other components, Form Layout is a component that is not visible on the page.

Examples:

Read-only examples include:

  • Organization of auxiliary information that appears above other components or within context regions. For example, in an HR application, when performing an action on an employee such as adding a newly born child to a table of family members—Form Layout would be used in a context region to display the employee's name, Social Security number, and department, to maintain the context for which employee is being updated.
  • Organization of data on the review page of a multi-step process.

Editable examples include:

  • The equivalent of a paper form, such as a medical form where the user would provide name, address, insurance, symptoms, and so on.
  • Organization of search criteria in a Query component.

Usage:

  • A page may contain more than one form layout.
  • The Form Layout component may appear inside the following regions:
    • Header
    • Context Region
    • Query Region
    • Panel Box
    • Disclosure icon
    • Panel Accordion

Definitions Bookmark this Heading Return to Top

The following terms are used to describe form layouts:

  • Pair: A single editable or read-only component associated with a prompt.
  • Combination: A combination of multiple standard web widgets sharing the same prompt.
  • End Facet Text: Text which appears after the data or web widget in a pair, such as monetary units or units of measurement.
  • Group: A collection of prompt/data pairs and combinations.
  • Child Group: A collection of prompt/component pairs that are related to a parent component in a form layout.
  • Section: Region of page starting beneath a section/subsection header and continuing until the next section/subsection header (if present).
  • Gutter: Gap between two columns.
  • Start and End Alignment: Internationalization terms for left and right alignment, because left-to-right order is reversed in some translated applications.
  • Top Alignment: When prompts render above standard web widgets or data instead of at the start or end.
Note: Where it helps improve clarity, this guideline uses the terms "left" and "right" instead of "Start" and "End" to simplify explanation of relative placement of web widgets. Note that in right-to-left languages, the order is reversed.

Configurable Elements Bookmark this Heading Return to Top

Product teams configure the Form Layout component with the following elements:

  • Grid
  • Columns
  • Group
  • Child Group
  • Field Group
  • End Facet Text
  • Form Layout Properties

Grid Bookmark this Heading Return to Top

Purpose:

Sets the basic pattern of the form layout.

A form layout grid showing each column taking 16.5% of the space, and 8-pixel-wide grid verticla grid lines.

Form Layout Grid

Description:

  • The grid is invisible to the user.
  • The total width of the grid occupies 99% of the available horizontal space.
  • The sections of the grid control both component and prompt width within the form layout.
  • Start-aligned prompts always wrap when they exceed the full width of a section.
  • Top-aligned prompts wrap when they exceed the total width of all sections available for a column.

Usage:

  • By default, the grid is divided into six equally spaced horizontal sections. Each section occupies 16.5% of the total width of the available horizontal space for the form layout. Teams can reset the section width based on percentage to accommodate components with widely differing widths.
  • Each type of component has default width settings within the form layout. See the individual component guidelines for details. Development teams may override these defaults when needed to best organize their data.
    • Select Radio and check box values automatically wrap when they exceed the total width of sections available for the column.
    • Sliders automatically extend to occupy the full width of a section or multiple sections if space is available.
    • Read-only components should occupy the same width as editable components. Data may be set to wrap, truncate, or scroll, depending on component type and data-specific requirements.
    • Spin boxes should not be auto scaled.

Columns Bookmark this Heading Return to Top

Sampes form layout columns: two- and three column groups

Form Layout Columns (Two- and Three- Column Groups)

Purpose:

A column spans grid sections to vertically group form layout elements.

Description:

  • The width of a component is restricted, by default, to the maximum number of sections available for the column.
  • Start-aligned prompts are end-aligned within the first section in a column. Top-aligned prompts are start-aligned with the fields within the first section in a column.
  • When the user resizes the browser, all sections and the fields within resize accordingly. The prompts of the components in form layout wrap when they exceed the width of the containing section. The width of a section and all fields within that section stop resizing if one or more of the fields are set with a fixed width.

Usage:

  • By default, a form layout has one column. Product teams may set a form layout to contain up to three columns by having columns span different numbers of grid sections. The table below shows the range of options.
  • The number of columns used should be based on the number and width of fields which need to be organized within the form layout and the space in which the form layout will reside.
  • Development teams control column width by specifying the width of the sections in that column.
  • When the form layout contains multiple columns, a component can be set to span across a single column or across all columns. This is used when a lengthy amount of information needs to be entered and displayed, such as a description within a text area. The spanning component should always be rendered as the last component in the first column in the form layout. The table below shows maximum span across columns.
  • In a multiple column layout, the number of prompt/data pairs in the form layout should be displayed in each column evenly, with the exception of groups and child groups.
  • Product teams can set prompt width and field width as percentages of the column. The default prompt width is 33%; the default field width is 67%. Nevertheless, it is not recommended to change the default widths except in the following cases:
    • When it is necessary to align different instances of form layouts with one another.
    • When working with unbalanced prompt/data pairs (very short prompts but very long data fields), changing the default prompt width attribute can help avoid an unbalanced right bias in the layout. It may also be necessary to place the unbalanced prompt/data pairs into their own form layout while keeping the balanced ones in another form layout. In such cases, the gutters of all the prompt/data pairs do not need to align.
  • Product teams can customize the layout by setting the number of rows (of web widgets) and maximum number of columns for a specific form layout.
Number of Columns Prompt Section Maximum Section Span without Column Span Maximum Section Span with Column Span
1 1 5 n/a
2 1, 4 2 5
3 1, 3, 5 1 3, 5

A single column layout in a dialog box

Single Column Layout in Dialog Box

A page with multiple form layouts in page sections

Page with Multiple Form Layouts in Sections

Group Bookmark this Heading Return to Top

Purpose:

Separates one set of prompt/data pairs from another.

Component groups on a page: a spin box, check box group, radio button group, and file upload.

Component Groups

Usage:

  • A group always renders within the same column in a multiple column layout.
  • Vertically stacked groups should be visually distinguished from each other by a separator line.
  • When a group contains components that span across all columns, the group should be rendered as the last group in the first column.
  • A form layout may contain as many groups as necessary to break up the data into logical chunks or sections.

Child Group Bookmark this Heading Return to Top

Purpose:

Combines a set of prompt/data pairs beneath a parent component.

A page showing radio button groups with child groups.

Radio Buttons with Child Groups

Usage:

  • A child group should be used if it is important to communicate that a section of data is contingent upon another section of data, or a section of data represents a subset of information.
  • A child group should be indented under its parent component with a horizontal indentation of 20 pixels.
  • A form layout may contain as many child groups as necessary to organize the data.
  • Child groups typically consist of text fields or choice lists, but may contain any web widgets.
  • Child groups are usually associated with a parent radio button in a radio group or parent check box within a check box group, but may be associated with any parent component.
    • A radio group should be in single column when it contains a child group.
    • If a component within the child group is selected or altered, product teams should code the parent radio item or check box item to auto-select.
  • The prompts in the child group should generally be top-aligned (stacked on top of the component). However:
    • Prompts may be start-aligned in some circumstances, such as in check boxes.
    • Form layout supports mixing top- and start- alignments using nested child groups.
  • Child groups can be oriented vertically as a single column or horizontally in multiple columns.
    • A child group always renders within the same column as its parent component. A component within a child group may be set to span across all columns. In this case, the child group together with its parent component should occupy the bottom right area of the form layout. Within a single form layout, no other components should be placed below or after a child group than spans multiple columns.
    • Child groups can be displayed in a single column when:
      • The page or section layout is either one or two columns.
      • Prompts and fields, data, or components in the child group are too wide for a multiple column layout.
      • Field groups exist in the child group.
    • Child groups can be displayed in multiple columns when:
      • The parent form layout is a single column.
      • Prompts and fields, data or components in the nested group are short.
      • Minimizing vertical spacing becomes important.
      • The child group does not contain field groups (they may cause horizontal scrolling).
  • Child groups may be enabled, disabled, shown or hidden using Partial Page Rendering (PPR) based on a user choice in the parent component.
  • A parent component may be related to multiple child groups.

Single-Column prompt/data group nested within a radio group on a page

Single-Column Child Group Nested Within a Radio Group

Multiple-Column prompt/data groups nested within a radio group on a page

Multi-Column Child Groups Nested Within Radio Groups

Nested prompt/data group in a two column page section

Nested Child Groups in a Two Column Page Section

Field Group Bookmark this Heading Return to Top

Purpose:

Combines multiple components with a single prompt.

Field group combining multiple components with one prompt.

Field Group

Usage:

  • A field group must contain at least two components sharing the same prompt.
  • A field group can consist of any combination of components and buttons. Common configurations include:
    • Text field with radio items, check box items, or select choice list
    • Select Choice list with text field or choice list
  • Components within a field group may contain dependencies.
  • The prompt for the first component in the field group also functions as the prompt for the entire field group.
  • The total width of the field group is restricted to the maximum number of sections available for the column. Product teams may set the field group to span across all columns.
  • It is recommended to limit field groups to no more than three fields in a two-column layout. If more than three fields are needed in a field group, then it is recommended to use a single column layout to accommodate the very wide field group.
  • Field groups are typically wider than single components, so are not recommended in three-column layouts unless:
    • The field group contains short components, such as two spin boxes.
    • The field group is set to span all three columns.
  • A field group may contain iconic duplication buttons, as shown in the following subsection.

Duplication Buttons Bookmark this Heading Return to Top

Purpose:

Create a copy of a component that users can configure with different properties.

Duplication Buttons in Field Group

Duplication Buttons in Field Group

Usage:

  • Duplication buttons are optional iconic buttons, which may render at the end of a field group.
  • Duplication buttons always appear in a pair: one Remove button (with - minus sign) and one Add button (with + plus sign).
  • The tooltip text for Duplication buttons should be: "Add Field Group" and "Remove Field Group".
  • Duplication buttons are useful when the user's task involves building a filter that uses the same fields, but where combinations of different values yield different results.
  • Before the field group has been duplicated, the Remove button is disabled; it is enabled as soon as the field group has been duplicated.
  • There is no default limit for the number of times a field group can be duplicated. Nevertheless, product teams may set a limit. Once the user reaches this limit, all Add buttons are disabled.
  • Field groups are always duplicated with their default values. Even if the user changes a value before clicking the Add button, the new field group still renders with the default values.
  • It is impossible to remove all instances of the field group; whenever only one exists, the Remove button is disabled.

End Facet Text Bookmark this Heading Return to Top

Purpose:

Provides additional context about data within a label/data pair.

Example of end facet text

Example of End Facet Text

Usage:

  • End facet text is optional text which may render at the end of a pair or field group.
  • End facet text provides additional information about the data portion of the label/data pair.
  • Common examples of end facet text are:
    • Units of length (for instance, feet, inches, meters, yards, centimeters)
    • Distance (for instance, miles, kilometers, acres)
    • Weight (for instance, pounds, kilograms, grams)
    • Units of measure (for instance, tablespoon, teaspoon, cup, liter, pint, quart)
    • Monetary denominations (for instance, cents, dollars)
    • Currency (for instance, Peso, Pound, Mark)

    See the Common Formats guideline for information on numeric formats and abbreviations in form layouts.

Form Layout Properties Bookmark this Heading Return to Top

Purpose:

Control height, width, and prompt alignment of a form layout.

Description:

  • The height of the form layout depends on the elements placed within it, and cannot be set by development teams.
  • The width of the form layout is 99% of the parent region, and cannot be set by development teams.
  • Prompt alignment of the form layout component controls the alignment of all prompts (except child group prompts) within the form layout.

Usage:

  • By default, prompts are start-aligned. Product teams may set the prompt alignment to be top-aligned.
  • Top alignment is usually reserved for child groups but may also be used for all prompts in a form layout if horizontal space is tight.
  • It is not recommended to use top alignment with read-only data because it is difficult to distinguish prompts from data.
  • Prompt alignment should only be set within a form layout and should not be set directly at the individual component level.

Controlling and Dependent Fields Bookmark this Heading Return to Top

Partial Page Rendering (PPR) can be used to refresh portions of page content when users make selections in primary fields that control display of that content. For example, when a user selects an option in a select choice list, related fields below that choice list may change to reflect the choice. In this case, the select choice list is referred to as the "controlling" field, and the related fields are referred to as "dependent" fields.

Principles for use of controlling and dependent fields are as follows:

  • Controlling fields must be placed above or before (left of) dependent content (fields, web widgets, tables, or tree tables).
  • Controlling fields can be used in many different ways, such as:
    • Selecting "Employee" in a controlling field in an HR application displays only employee-specific fields (hire date, review date, and so on). Conversely, selecting "Manager" displays manager-specific fields (number of subordinates, level of signature authority, and so on).
  • The following components may function as controlling fields in a form layout:
    • Select Choice lists
    • List boxes
    • Radio groups
    • LOV text fields
    • LOV choice lists
    • Check boxes
    • Spin boxes
  • Depending on the selection in the controlling field, dependent fields may be added, removed, enabled, disabled, change content, or remain unchanged. See the images below for examples.
  • When dependent fields change, associated Help text may also change.
  • If the controlling field has no default selection, all dependent fields may remain hidden until the user makes a selection.
  • A controlling field may render a required dependent field. If so, the required indicator must be displayed next to that dependent field.
  • PPR should be avoided when most of a page's content needs to be redrawn, or time-consuming queries are needed to generate/refresh the content.

Controlling field adds or removes components below

Controlling Field Adds or Removes Components Below

Controlling field changes content in dependent fields

Controlling Field Changes Content in Dependent Fields

Controlling field changes content and/or adds/removes components

Controlling Field Changes Content and/or Adds/Removes Components

Multiple controlling fields with multiple dependencies

Multiple Controlling Fields with Multiple Dependencies

Tabbing Through Form Layout Fields Bookmark this Heading Return to Top

The tab order through fields in a form layout is as follows:

  • The form layout follows the default browser order from top to bottom within a column, and from the leftmost column to the rightmost column when more than one column is present (order is reversed in right-to-left languages). For example, in a 3-column form layout, tabbing traverses down the first column, over to the second, down the second, over to the third, and down the third.
  • Groups and child groups within a form layout follow the same tabbing behavior: down, then across.
  • All components within a field group are traversed (start to end) before tabbing focus moves to the next component in the form layout. The image below shows the sequence.
  • If a component spans more than one column within a form layout, the tabbing behavior is altered slightly; all components above the spanning component gain focus before the spanning component in tab traversal.
  • When tabbing to a radio group, the browser determines the behavior:
    • Windows® Internet Explorer®, Apple Safari®, and Google Chrome® treat the radio group as a single control, requiring users to press arrow keys to move though the radio buttons.
    • Firefox® treats the radio group as a set of controls, so pressing the Tab key navigates through the radio buttons, as shown in the images below.

Showing stops of a tab traversal within a field group

Tab Traversal with Field Group

Tab traversal with a spanning component

Tab Traversal with a Spanning Component