The Model: -
The model component is implemented using the BC4J. BC4J consists of three components:-
-->Entity Object and Associations.
-->View Object and View Link objects.
-->Application Module.
Entity Object: - Entity Objects represents a database row in middle-tier. Database rows are
represented as individual entities, in which attributes typically correspond to columns in the
corresponding table to automatically implement queries, inserts, updates and deletes. Entity
objects can also be based on views, synonyms or snapshots. Most entity objects that you create
subclass the oracle.apps.fnd.framework.server.OAEntityImpl class. Entity Objects are also used
to implement the business validations. Associations are used to establish the relationship between the entity objects. When you create an Entity Object, framework will provide you a Java class with the setter and getter methods corresponding to each column of the table to which you’re Entity Object is based on. And along with that it will provide you following methods which are called by framework itself on appropriate event:-
protected void validateEntity( ) - Any validation involving two or more attribute values on the
entity should be included in the validateEntity() method.
public void create() - add any defaulting/initialization code, such as getting the value of a
sequence and then assigning it to the corresponding attribute.
public void remove() - If you need to implement any special delete behavior (like
checking to see whether the delete action is allowed, or implementing cascade-delete), you should
add code to your entity's remove() method.
View Object:-
View Object accesses the result set of a SQL statement. It can be either based on the Entity Object or on plain SQL query. A view object is a business component that encapsulates
SQL code and metadata that maps columns in the select statement to the attributes of one or more entity objects, if it is based on the Entity Object. A view object use SQL to join, filter or sort
business data or to shape it for presentation. View objects provide row sets that can be viewed or used to update the underlying entity objects. You can define multiple view objects per entity object or a view object can select data from multiple entity objects. View Object can be created
declaratively or programmatically. Which ever way you create it, you need an application module to contain it. View objects are not an appropriate home for business logic; we should not be writing validation rules in our view objects or view rows. All view objects that you createsubclass the oracle.apps.fnd.framework.server.OAViewObjectImpl class.
Application Module: -
A logical container that manages and provides access to "related" BC4J model objects. It
represents the data model that client uses. To create the data model, the application module
contains business components, including instances of view objects and view links. An application
module may be a root application module or a nested application module. A root application
module is not contained in another application module. It provides transaction context for all
objects it contains. Root application module also maintains the database connection. All application modules that you create subclass the oracle.apps.fnd.framework.server.OAApplicationModuleImpl class.
The View:-
The View formats the data and presents the data to the user. In OAF View is implemented using
the UIX. UIX uses XML to describe the components and hierarchy that make up an application
page. UIX also provides runtime capabilities to translate that metadata into HTML output so that it can be shown on a Browser or a mobile device. The metadata used to describe the UI is loaded into a database repository, called Meta Data Services (MDS), at deployment time and optionally at design time as well. Pages are developed declaratively using the Oracle 9i Jdeveloper OA Extension. Pages are made up of hierarchy of regions and items. Each UI widget corresponds to one or more Java objects (beans). And these java beans are used to create the HTML at runtime. When you design a page, you store "page definition" in XML format on your local machine. When deploying to our system/server, we load this XML file into MDS repository using the xml import statements. When the user run the page in the browser, the page definition is fetched from the MDS repository and is converted into the XML file by the MDS engine. Each component in XML is translated into the Java web bean object. And this web bean is rendered by the OA Framework. Page definition is cached in to the memory, and if it is there, framework will not go to MDS repository to get the page definition.
The Controller responds to user action and direct application flow. It provides the wiring between the UIX web bean and the middle-tier. All the controllers that we create subclass the
oracle.apps.fnd.framework.webui.OAControllerImpl. When the browser issues an OA.jsp request:-
The oracle.apps.fnd.framework.webui.OAPageBean(the main OA Framework page processing class) uses the page name to determine which root AM it refers to, so that the VO’s related to the page can be accessed. Then user session is validated and then OAPageBean evaluates request parameter or figure out if it dealing with an HTTP POST or GET request. During the iteration, if the framework finds a web bean referencing a controller class it will call one of the following methods.
custom code can call the application module to initialize and query the data. This phase may
optionally construct or modify the web beans to create or alter the page structure and web bean
properties.
Process Form Data - This phase is invoked upon a browser 'Post'. During this phase the
framework will automatically applies form changes back to the underlying view objects. Rarely is
custom code required in this phase. If exceptions are thrown during this phase, the Process Form Request phase is skipped and the page is redisplayed.
Process Form Request - This phase is invoked upon a browser 'Post', assuming no exceptions
were thrown during the Process Form Data phase. This is were custom code can handle the form
submit events and call the application module to process the event.
Framework passes two parameters OAPageContext and OAWebBean to the processRequest and processFormRequest. Following are the usages of OAPageContext parameters.
1. To get and set values of the fields, using oapagecontext.getParameter and
oapagecontext.putParameter
2. For redirecting to the current page or another page. For example to redirecting to current page
itself use oapagecontext.forwardImmediatelyToCurrentPage. Or you may use
oapagecontext.sendRedirect(snewpage)
3. To get a handle to application module(remember we attached AM to page)
oapagecontext.getRootApplicationModule()
4. Write debug messages, using oapagecontext.writeDiagnostics
5. Get message text from FND Message dictionary, using oapagecontext.getMessage
Usages of parameter OAWebBean:-
Remember that webbean represents the hierarchy/structure of components in the page. Hence
using this paremeter object, you can get a handle to any bean/component in that page hierarchy.
Once you have a handle to that bean (say field bean or button bean), you can then invoke methods like setRendered etc to change the behaviour of page at runtime.
Some examples are
1. OAWebBean LastName = oawebbean.findIndexedChildRecursive("personLastName");
Note: In this example, our page must have just one field whose name is personLastName
2. Get a handle to region
OAStackLayoutBean oastacklayoutbean =
(OAStackLayoutBean)oawebbean.findIndexedChildRecursive("stackRegionName");
0 comments:
Post a Comment