oracleADF

OracleOrderMgmt

Google Photos Blog: Showcasing photos from people you care about

Google Photos Blog: Showcasing photos from people you care about

OAF

Link For OAF

Please refer metalink notes for OAF developer guides.

Oracle Application Framework Developer's Guide Release 12.1.3 [ID 1107973.1]
Oracle Application Framework Developer's Guide Release 12.1.2 [ID 972774.1]
Oracle Application Framework Developer's Guide Release 12.1.1 [ID 744832.1



Link for Finding proper version of Jdev

 How to find the correct version of JDeveloper to use with eBusiness Suite 11i or Release 12]


Metalink note for finding latest OAF dev guide :-> Note 395441.1 

 if available, including known issues addressed in that patchset by referring to the
Oracle Application Framework Documentation Resources, Release 12 (Metalink Note
391554.1).

Oracle DOES NOT Support STD OAF PAGE Controller Changes

Oracle does not recommend that customers extend controller objects associated with
regions or web beans in shipped E-Business Suite product pages. Controller class
(oracle.apps.fnd.framework.webui.OAControllerImpl) methods should
effectively be considered private, since their implementation is subject to change.
Controller extensions are therefore not considered to be durable between upgrades. If it
is absolutely essential to handle custom form submit events on a shipped product page,
processFormRequest() is the only method that should be overriden in a controller
class, although the risks outlined above still apply .


what is passivation?

OAF Jargon

partial page rendering (PPR), 
hot keys, 
smart choice lists 
and 
auto-completion of fields with lists of values 


BLAF <>>> the bluff--> Marketing!!

BLAF (Browser-Look-And-Feel) guidelines. BLAF is the default look and feel that all OA Framework applications assume,
but can be personalized in many ways to meet customer branding and style requirements. OA
Framework's implementation of BLAF standards yields a consistent user experience and further
enhances user productivity


OAF follows MVC architecture


Model --> Business Logic--> 
View --> UI
Controller--> Business Flow


 


Model --> BC4J
 View --> UIX
Controller -->
 


 


 









 


 

Window Block

Previous | Page 1 of 2 | Next

Windows and Blocks

Form Builder processes many events based on blocks (and items), which can be completely independent of windows (and canvases). Keep in mind the following characteristics of windows and blocks.

Connection Between Windows and Blocks

	A window can contain multiple canvases, and multiple items can be located on a canvas.
	A block can contain multiple items, and an item is located on one and only one canvas (except for null canvas items).
	A window can contain multiple blocks, and a block can be located on several windows.

Note: In general, put blocks in separate windows. If blocks are closely related (through a foreign-key relationship), put them in the same window.

Window Activation and Block Navigation

You can use the When-Window-Activated trigger to activate another window automatically (see the Closing Windows example later in this module).

Transaction Management

During commit processing, Forms processes all base blocks in sequential order. Therefore, transaction management is block-based rather than window-based. However the user expects to interact with a form in a window-based manner.

Manipulating Windows

Using Window-Interaction Triggers

You can use four window-interaction triggers to provide extra functionality whenever a user interacts with a window. These triggers should be defined at the form level.

Using Window-Interaction Triggers

The common uses for these triggers are as follows:

Trigger	Use
When-Window-Activated	Captures initial settings of window properties; enforces navigation to a particular item whenever the window is activated.
When-Window-Deactivated	Deactivates a window.
When-Window-Closed	Closes a window programmatically.
When-Window-Resized	Maintains visual standards; captures window properties.

Keeping Track of the Triggered Window

The SYSTEM.EVENT_WINDOW system variable contains the name of the last window for which a window-interaction trigger fired. You can use this system variable to perform different actions for different windows in your window-interaction triggers.

Trigger	Characteristic
When-Window-Activated	Fires when a window is made the active window. (Note that window activation can occur independently of navigation).
When-Window-Deactivated	Fires when a user deactivates a window by setting the input focus to another window.
When-Window-Closed	Fires when a user closes a window by using a window-manager-specific Close command.
When-Window-Resized	Fires when a window is resized, either by the user or through a trigger. (It also fires at form startup, but not when a window is made into an icon).