Technical analysis of EBS OAF page (2)_html/css_WEB-ITnose

(Copyright statement, if you need to reprint my original or translated articles, if you reprint them for personal study, please indicate the source; otherwise, please contact me, violators will be prosecuted)

Original text From OAF development documents

OADBTransaction

Figure 5: Basic model architecture-OADBTransaction

Note: To be completely accurate and compatible, this diagram should contain the implementation class oracle.apps.fnd.framework.server.OADBTransactionImpl instead of the oracle.apps.fnd.framework.OADBTransaction interface, nevertheless , we chose to include it later because you only use this interface in your code.

As shown in the above figure, OADBTransaction plays a central role in your model code because it encapsulates the JDBC connection/database session associated with the root application module and directly owns all the entity objects you create ( Your view objects owned by the root application module hold references to their entity objects on their view rows). You would also normally use OADBTransaction in your model code for the following common behavior:

l Create a callable statement to execute a PL/SQL method or procedure.

l Access session-level application context information such as username, ID, current responsibilities, etc.

l If you need to perform NLS operations such as converting server date/time to user date/time, etc., you can access the oracle.apps.fnd.framework.OANLSServices object.

Access to OADBTransaction is provided by the root application module.

Interface view

Interface view formats and displays model data to the user.

The following content is introduced in detail in the implementation interface view of Chapter 3.

Define Pages

During development, you can specify the bean hierarchy for each page using the declarative JDeveloper tool in Building “Hello, World” There is an introduction. In Oracle E-Buisness Suite development, you will use (source control) XML files for page definition. When your product is deployed to a customer's site, the OAF framework runs these page definitions out of database storage.

Introduction In a nutshell, you can use JDeveloper to define pages consisting of areas and items.

l Items are simple widgets like buttons, fields, images, etc. that do not contain children Gizmo for controls.

l The area is a container object, which can contain items and other areas. Areas are examples of headers, tables and special layout components.

l Each area and item you define has a style attribute, which tells the OAF framework how to instantiate this web bean at runtime (this also indicates what HTML to generate for this bean) . For example, if you define a region whose style attribute is "table", then OAF will instantiate an oracle.apps.fnd.framework.webui.beans.table.OATableBean object.

l All pages must have a top-level area (generally called the "root area") whose style is pageLayout and will be instantiated as oracle.apps.fnd.framework.webui.beans.layout .OAPageLayoutBean object.

l The order of areas and items in the JDeveloper page tree (and corresponding XML file) tells the OAF framework where to add these objects to the runtime bean organization hierarchy.

Figure 6 below gives a behind-the-scenes look at the various web beans for an instantiated example page. The label you are looking at is the name of the web beans behind it. For example, a pop-up list is instantiated as oracle.apps.fnd.framework.webui.beans.message.OAMessageChoiceBean, and a submit button is instantiated as oracle.apps.fnd.framework.webui.beans.form.OASubmitButtonBean.

Figure 7 shows the corresponding page definition.

Figure 6: The UI component page shows the name of the corresponding web beans

Note: The area and item names shown below are not Comply with Oracle EBS naming standards; instead, they are used to help you interpret the corresponding structure into the corresponding web beans.

Figure 7: Page structure in JDeveloper

Attribute Set

Each area or item can use an attribute set to inherit the settings of the attribute group. A property set is a named, reusable property collection that can identify any type of UI object property, including area, item, and other property sets. Whenever you build a UI that uses property sets, you can override inherited properties (although this is discouraged in the OAF programming standards).

To demonstrate this concept, in application development, each table must have an associated set of properties for each display column. These property sets include tooltips, display width, and more.

l In the OAF ToolBox Sample Library/Tutorial, there is a purchase order table (FWK_TBX_PO_HEADERS) whose primary key column type is NUMBER and named HEADER_ID, which is also displayed to the user as the purchase order number.

l This table has an associated FwkTbxPoHeaders attribute set XML package file, which contains attribute sets for all displayed columns in the table (one attribute set for each column). One of the attribute sets is called HeaderId.

l The HeaderId attribute set has a Prampt attribute set to Order Number and the display length is set to a reasonable 15.

l When you create a purchase order containing When coding the Item's page, we can set its attribute set attribute to the completely appropriate attribute set named /oracle/apps/fnd/framework/toolbox/attributesets/FwkTbxPoheaders/Headerid.

Figure 8: Using a property set in JDeveloper

Component reuse

Component Reuse

If you want to include shared objects into your page, you can simply inherit from them.

For example, in OAFToolBox Sample Library/Tutorial, we created a common area (named PoSummaryRN) so the same content can be included in multiple pages without encoding. To add a shared area to a page, we simply create a new area and set its Extends property to the qualified full name of the shared area: /oracle/apps/fnd/framework/toolbox/tutorial/webui/ PoSummaryRN

Note: On the reference page, the shared area is not editable, so its items are gray in the JDeveloper structure panel.

Figure 9: Expanding a region in JDeveloper

Data source binding

For any beans that need to interact with the database (query, insert, update and/or delete), you also need to specify a binding to the View Instance Name data source and associate the View Attribute Name. This binding is crucial , because the OAF framework uses it to obtain query data from the underlying view object or write user-entered data to the view object instance.

l The View Instance Name property refers to the underlying view object in the context of the application module it contains (all view objects "live" in an application module and are identified by the instance name within its container ). For example, if a SupplierVO view object is identified by the instance name "MySupVO" in the root application module of your page, "MySupVO" will be the name you specify.

l View Attribute Name refers to an attribute in the underlying view object that is mapped to the column. For example, if you have a SupplierVO that has a "SupplierId" attribute (which maps to the underlying SUPPLIER_ID column), "SupplierId" is the name you specify here.

Define menu

All OAF applications like Oracle Browser Look and Feel (BLAF) UIGuideline: Tabs/Navigation. describe contain menus. You can define these menu structures declaratively using Oracle EBS's menu and function definition forms. We'll cover this in detail later in the development documentation.

Just like OAF will translate your declarative UI layout into the runtime bean hierarchy, it also contains declarative menu-defined web beans.

Define page flow

When dealing with multi-page transaction flows, the OAF framework provides a declarative (and therefore customizable) approach to complex hard-coded controller logic. Additional information about this feature can be found in Chapter 4: Declarative Pageflow UsingWorkflow.

Personalization page

The OAF framework also includes a declarative customization infrastructure called OA Personalization Framework. This is for end users and product release chain Supports customized responses (change localization, arrangement, etc.).

Note: As you can see in the development documentation, it is better to create areas and items declaratively rather than programmatically. In fact, you should only create components programmatically if you can't create them declaratively, so clients can personalize your work.

Controller

The controller responds to the user's actions and directs the application flow.

The Implementing the Controller documentation in Chapter 3 describes the following in more detail.

Controllers can be associated with interface views at the zone level (from a more general perspective, any OAF web beans that implement the oracle.apps.fnd.framework.webui.beans.OAWebBeanContainer interface can be associated with controller).

All controllers you create inherit from oracle.apps.fnd.framework.webui.OAControllerImpl as shown in Figure 10 below.

Controller classes are the classes where you define how webbeans behave. In particular, you write controller code to:

l Manipulate/initialize the UI at runtime (including any programmatic layout that cannot be implemented declaratively)

l Intercept and Handle user events such as button presses.

Request processing

When the browser issues an OA.jsp request for your page:

1.        oracle.apps.fnd.framework .webui.OAPageBean (the main OAF page handling class) uses the page name to decide which application module it needs, so it can pull its application module instance from the application module pool. The application module will also retrieve a JDBC connection from the connection pool, and the page's transaction context will be established.

2. Verify the user session; if invalid, the login page will be displayed (note that this is for simplicity; more details will be mentioned in later development documents).

3. Assuming the user is valid, OAPageBean will determine whether it is processing an HTTP POST or GET request based on the request parameters.

Handling GET requests

When the browser issues a GET request to the server to request a page (or you manually redirect it), the OAF framework uses the declared UI Definition to build the web bean hierarchy:

1. OAPageBean will call the processRequest() method of the pageLayout bean at the top of the page, and then the entire web bean hierarchy will be recursively processed as follows to initialize web beans (including any associated Model component):

1. Each web bean instantiates its controller, if it has one, and calls the processRequest(OAPageContextpageContext, OAWebBean webBean) method on the controller. This method is what you use to build/modify your page layout, set webbean properties and do any manual data initialization (if, for example, you need to do automatic queries when you navigate to a page).

2. Some complex webbeans (like oracle.apps.fnd.framework.webui.beans.table.OATableBean and oracle.apps.fnd.framework.webui.beans.layout.OAPageLayoutBean) need to be called by calling them The prepareForRendering() method is used for post-controller processing (this method is described in detail in the corresponding bean Javadoc).

3. Each web bean calls the processRequest() method of its child control.

2. oracle.apps.fnd.framework.webui.OAPageBean hands over the web bean hierarchy to UIX to generate the page and send it to the browser.

Handling POST requests

When the browser makes a POST request to the server for a page:

1. OAPageBean checks whether the web bean hierarchy is already in memory. If not (because the resource has been reclaimed, the user navigated via the browser's back button, or a POST request was made from a message dialog page to the main page), it will be restarted as described above in GET request handling. Create a hierarchy.

2. OAPageBean calls the processFormData(OAPageContextpageContext, OAWebBean webBean) method of all beans in the hierarchy to write the form data back to the model (specifically, it will call the processFormData() method on the pageLayout area , and then each web bean recursively calls the processFormData() method on its child controls). Writing back form data to the corresponding model automatically invokes property and entity level validation, and if you throw any validation exceptions, processing is terminated and an error message is displayed to the user.

3. If no exception is thrown during the processFormData() stage, OAPageBean will use the method described above to call the processFormRequest(OAPageContextpageContext, OAWebBean webBean) method of the web bean in the hierarchy. This gives your controller code the opportunity to respond to the user's actions accordingly.

4. If no JSP redirection or page redirection request is issued--or an exception is thrown in processFormRequest()? Then the page will be refreshed.

OAPageContext

When the OAF framework receives an OA.jsp request, OAPageBean will create an oracle.apps.fnd.framework.webui.OAPageContext object. This class Exists only during processing of the page. Each of the three important methods described above (processRequest(), processFormData() and processFormRequest()) takes an OAPageContext as a parameter, and any controller code you write will make use of this important class.

Figure 10: The relationship between the OAPageContext class and other key classes

As the above figure demonstrates, OAPageContext has pairs of requests and a reference to the root application module. With these relationships in place, the OAPageContext is passed to each of your controller's response handling methods, and you can see how to use the OAPageContext for the common tasks listed below:

Accessing request parameters

Possibly most important, this is the class you use to read request parameter values, by calling a simple method getParameter(Stringname) (remember that the request contains all URL parameters plus ? if it is a POST Request? All form field values, plus the name and event of the associated action/control component selected by the user).

Tip: For individual web beans (buttons, fields, etc.) on your page, the value of name passed to getParameter() is the corresponding identification ID that you assigned when defining the page. So, for example, you could write the following code in your controller Ahri knows if the user pressed the button you named "GoButton" in JDeveloper

processFormRequest(OAPageContextpageContext, OAWebBean webBean){ if (pageContext.getParameter("GoButton") != null) {   // The user pressed the "Go" button, do something... }}

Access Root application module

OAPageContext缓存了根应用模块的引用，其可以提供对视图对象和事务的访问。如果你需要访问一个应用模块，可以像下面：

processFormRequest(OAPageContext pageContext, OAWebBean webBean){  OAApplicationModule am = (OAApplicationModule)pageContext.getRootApplicationModule();}

发出导航指令

你可以使用这个类的方法来告诉OAF框架来进行JSP转向或者一个客户端的重定向。比如（我们会在稍后的开发文档中对这个方法做更详细的介绍）：

processFormRequest(OAPageContext pageContext, OAWebBean webBean){  if (pageContext.getParameter("CreateButton") != null)  {    // The user pressed the "Create Supplier" button, now perform a JSP forward to    // the "Create Supplier" page.    pageContext.setForwardURL("OA.jsp?page=/oracle/apps/dem/employee/webui/EmpDetailsPG",                                   null,                                                           OAWebBeanConstants.KEEP_MENU_CONTEXT,                                                           null,                                                           null,                                                           true, // Retain AM                                                           OAWebBeanConstants.ADD_BREAD_CRUMB_YES, // Show breadcrumbs                                                           OAWebBeanConstants.IGNORE_MESSAGES);  }}

访问应用上下文信息

就像你的模型代码中的OADBTransaction，OAPageContext提供了对servlet会话层Oracle EBS上下文信息，比如用户名称,id,当前职责等等。比如，下面的代码片段演示了如何获取用户名称:

processRequest(OAPageContext pageContext, OAWebBean webBean){  String userName = pageContext.getUserName();}