Oracle ADF UI Development Tips and

Best Practices

Developer Tips
∗ Form Layout Correctly

Done using common components
panelLabelandMessage

Also after dragging and dropping the fields, we could also drag and drop a form layout in
to the structure window and make those fields child components of the form layout.

∗ Header – Footer and center area

To keep the header and footer area to stay anchored to top and bottom, and the
center area to take the rest of the space when the zoom in-out is done or size
changed.

Done using; Layout
panelStretchLayout

∗ Horizontal label sets created using adding input text fields inside panelGroupLayout
where its layout is ‘horizontal’
 ∗ Partial Page Rendering (PPR)

 For validating data fields as they are entered

Behavior
auto submit to “true”

 When change in one field should affect the values in some other fields
Behavior
Partial Triggers
edit expression

∗ Managed beans and backing beans

Similar in action, only that, beans having one-to-one mapping with UI

components in a page, which is backing the page, are called backing beans.
Managed beans are simple java classes with methods used to edit up the
functionality when some action is triggered.

1. adfc-config.xml
overview tab
managed beans (edit and fine tune the
bean)

2. From property inspector of the specific UI components, go to the necessary

component listener and make the managed bean by clicking edit.

Best Practices
To save a great deal of development trouble and reduce maintenance costs:

1. Never try to stretch something vertically when inside of a flowing (non-stretched)

container. Attempting to do this will result in inconsistent behavior across web browsers.
2. Never specify a height value with percent units. Instead, define such stretching
declaratively as by following the process outlined below.
3. Never use the "position" style.
4. Take advantage of the layout pattern examples for guidance on how best to create a
desired layout. Be sure to click on the "View Page Source" and the "View Template
Source" links of the demo to see what tags and attributes are used as well as what the
component structure looks like for each specific page.

• Branding Bar
• Form Layout
• Navigation-Master-Detail
• Stretched Header
• Tiled Flowing
• Tiled Stretching
Process for Creating Layouts: Artifacts
1. Create a stretchable outer frame
o Build up the outer structure of your page using a structure of components that
support being stretched and also stretch their children.
o Each layout or panel component's tag documentation will identify whether this is
supported and how to achieve it in its Geometry Management documentation.
Some components have attributes to determine whether children will be stretched
or not. For example:

 document has its maximized attribute. Try the maximized attribute NOT
SET on the document component.
 showDetailItem has its stretchChildren attribute.

o Typically you would use various combinations of the decorativeBox ,

panelSplitter , and panelStretchLayout components inside of your document
component to create the stretchable outer frame.
o Also, consider using pageTemplates , declarative components, and regions for
reuse and centralized maintenance.

2. Create flowing islands

o Inside of the stretchable structure created in step 1, you can create islands of
flowing (non-stretched) components. To make this transition from stretching to
flowing, use panelGroupLayout with layout="scroll" since it supports being
stretched but will not stretch its children.

o For a reliable page layout:

 Do not specify heights using percent units.
 Do not use the position style.
 Do not attempt to stretch anything vertically inside of these flowing
islands.

o Many leaf components do not make sense by themselves. For example, if you
have a series of input components, you would never want to just place these in a
panelGroupLayout because it would be much better for usability if you placed
them in a panelFormLayout so the labels and fields align.

o A sample list of components that cannot be reliably stretched includes:

 Most input components
 panelBorderLayout
  panelFormLayout
 panelGroupLayout with layout="default" or layout="horizontal"
 panelHeader with type="flow" - see the Stretched Header example for an
situation where content below a header is stretched
 panelLabelAndMessage
 panelList
 Apache MyFaces Trinidad HTML Component - tableLayout
 JSF HTML Component - panelGrid

3. Customize the appearance of components

o Appearance may be customized using the following mechanisms:
 Use themed decorativeBox components to organize your page layers with
visual distinction and decorative borders as seen in some of the sample
skins. Note that not all skins have alternative themes so you may not see
any distinction. If your decorativeBox components are not showing up
with different colored backgrounds and you know that you are using a skin
that has definitions for alternate themes, you might be missing a web.xml
context-param setting for "oracle.adf.view.rich.tonalstyles.ENABLED"
being set to false.
 Your document component also has a theme attribute so you can use it to
change the main background styling of your page.
 Use a custom skin for consistently modified appearances if the existing
skin doesn't provide all that you need.
 For instance-specific alternative styling, use the styleClass attribute. Keep
the corresponding style definitions in an easy-to-maintain location such as
in a custom skin, in the metaContainer facet of the document component,
or in a style provided by the resource tag.
 As a last resort, use component attributes such as inlineStyle, contentStyle,
and labelStyle. These are less declarative, harder to maintain, contribute
more to the page's raw HTML size, and may not even be needed if one or
more of the above mechanisms are used.
 Styles are directly processed by the web browser, which gives you a great
deal of power but at the cost of being less declarative and error-prone. The
browsers do not support all styles on all elements and certain
combinations of styles produce non-obvious results. Here is some
guidance on style configurations to avoid:
Component Situations to Avoid
* An inlineStyle with a "height" value with "%" units
An inlineStyle with a "width" value between "90%" and "100%"
* (use styleClass="AFStretchWidth" or
styleClass="AFAuxiliaryStretchWidth" instead)
* An inlineStyle with "height", "top", and "bottom" values
* An inlineStyle with "width", "left", and "right" values
* An inlineStyle with a "position" value
Child being
stretched by a An inlineStyle with "width" or "height" values
parent component

 *Note: Avoid when possible throughout.

o Scrolling:
 You should only have scrollbars around flowing island content. The
recommended transition component for switching from a stretching outer
frame into a flowing island is the panelGroupLayout with
layout="scroll". If the contents of this panelGroupLayout cannot fit in
the space allocated, the browser will determine whether scrollbars are
needed and will add them automatically.

 It is not recommended that you nest scrolling panelGroupLayout

components because this will make the user see multiple scrollbars. Also,
this should only be used at transitions from stretching to flowing areas and
since you should not have stretching areas inside of flowing areas, you
would generally never end up with nested scrollbars. It is best to minimize
the number of areas that a user must scroll in order to see what he or she is
looking to find. Take time to consider what scrolling the user will need. In
cases where undesired scrollbars exist, you may want to simply change the
layout attribute of that panelGroupLayout to "vertical".

 There is a known scrolling issue that has been filed against Internet
Explorer 7.0.5730.11. The issue is only resolved in Internet Explorer 8
when running in pure IE8 rendering mode. If a scrolling box has contents
that are set to be as wide as the containing box and if the contents are large
enough to warrant the need for a vertical scrollbar, an unnecessarily-
needed horizontal scrollbar will be added. The browser is failing to adjust
the width of the contents for the presence of the vertical scrollbar and thus
 a horizontal scrollbar appears. This horizontal scrollbar lets you scroll the
small amount of space equal to the width of the vertical scrollbar. With
this issue, it is not recommended to specify a width anywhere between
90% and 100%. Smaller widths will generally not encounter the bug.
Workarounds (as seen in this page) involve setting the widths of the
contents to be smaller than full width so that the browser has enough space
for a vertical scrollbar to fit. For your convenience, a styleClass named
"AFStretchWidth" is built into the skin to specify that a component with
this styleClass will get a reduced width in Internet Explorer 7 or full width
in other browsers. If you need a smaller size for an thin auxiliary column,
you can alternatively use "AFAuxiliaryStretchWidth" or you may
create a similar skin definition in your own skin like this:

@agent ie and (version: 7.0) {

.AFIEOverflowWorkaround75 {
width: 75%;
}
}

o Margins, borders, padding:

 Thanks to the browser's "CSS Box Model rules", it is much harder to
define margins, borders, and padding on your components than what you
might expect. Refer to the Navigation-Master-Detail, Tiled Flowing, and
Tiled Stretching layout pattern examples for various mechanisms to apply
padding.
 In many cases, to apply these kinds of styles, you need to use multiple
components together. In a scrolling area, adding an extra
panelGroupLayout with layout="vertical" with the padding defined on it,
inside of the outer layout="scroll" panelGroupLayout, will be required. In
a stretching area, you may need to wrap a component inside of a
panelStretchLayout with spacers in its top, start, end, and bottom facets for
the padding.