Bit #28 - Using findDefObject() to load a BC definition object from its metadata XML

If you ever thought of parsing any of the ADF Business Components (BC) metadata XML files for the sake of extracting various metadata information, you might want to think twice. The ADF framework offers higher level APIs to do this routine job. Case in point: take a look at the findDefObject() methods available in a number of definition classes such as oracle.jbo.server.EntityDefImpl and oracle.jbo.server.ViewDefImpl for example. By calling this method, the metadata is parsed and loaded for you into the corresponding EntityDefImpl or ViewDefImpl. Neat! Then extracting metadata information is as easy as calling the corresponding methods. For example, to get all the attributes defined for a View Object, you can call ViewDefImpl.getAttributeDefs(). When calling findDefObject() ensure that the location of your BC definition files is listed in the class path. Here is an example:

Example:

import oracle.jbo.AttributeDef;
import oracle.jbo.server.AttributeDefImpl;
import oracle.jbo.server.EntityDefImpl;
import oracle.jbo.server.ViewDefImpl;

public class ADFMetaDataTester {

    public static void main(String[] args) {

      // load EO definition from Employee.xml
      EntityDefImpl eoDef = EntityDefImpl.findDefObject("Employee");
      // now, you can for example get the unique keys defined by the EO
      AttributeDefImpl[] uniqueKeys = eoDef.getUniqueKeys();

      // load VO definition from EmployeesVO.xml
      ViewDefImpl  voDef = ViewDefImpl.findDefObject("EmployeesVO");
      // get the VO attributes
      AttributeDef[] attributes = voDef.getAttributeDefs();
    }
}

Context:

ADF Business Components (BC)

Bit #27 - Setting a View Object attribute's Queryable property

Expanding on Bit #26 - Overriding getAttributeDef() to conditionally set an attribute property, you can set a View Object's attribute queryable property simply by calling setQueriable() on its ViewAttributeDefImpl. As explained in Bit #26, you can get the AttributeDef attribute definition by calling getAttributeDef() and passing the attribute index as a parameter. In order to call any of the attribute set...() methods, you will have to cast the AttributeDef interface to an ViewAttributeDefImpl implementation. By the way, did you know that by setting an attribute's queryable property will show or hide a View Criteria Item (i.e. the criterion) based on the attribute on the af:query dialog? Another way to hide the criterion was outlined in Bit #25 - Hiding a View Criteria item based on some condition. It will also show or hide the attribute from the Add Fields drop-down in the Advanced mode of af:query. One last thing: check-out the plethora of set...() methods available in the ViewAttributeDefImpl. As you may have guessed it, pretty much everything that is available declaratively on the Edit Attribute dialog, can be set (or reset) dynamically in your code based on some business condition. For a complete use case, check out the reference listed below.

Example:

  /**
   * Helper to set an attribute's queriable property.
   * Example:
   *    setQueriable(ViewRowImpl.SOMEFIELDINDEX, something.equals(somethingElse));
   *
   * @param attribIndex the attribute index
   * @param condition the condition (true/false)
   */
  protected void setQueriable(int attribIndex, boolean condition) {
      // set the attribute queryable as needed
      AttributeDef def = super.getAttributeDef(attribIndex);
      boolean queryable = condition;

      // set/reset queriable only if needed
      if (def != null && def.isQueriable() != queryable) {
          ViewAttributeDefImpl attributeDef = (ViewAttributeDefImpl)def;
          attributeDef.setQueriable(queryable);
      }
  }


Context:

View Object Implementation Class

References:

http://dstas.blogspot.com/2010/03/set-queryable-property-on-attribute.html

Bit #26 - Overriding getAttributeDef() to conditionally set an attribute property

You can override ViewObjectImpl's getAttributeDef() method to update an attribute setting, control hint or a custom property. getAttributeDef() is called by the framework each time the attribute's definition needs to be accessed, for example prior to opening an af:query search dialog. In such a case, this may be the ideal place to set a conditional queryable property for example. The argument that is passed to the method indicates the index of the attribute being accessed. You modify the attribute definition by calling super.getAttributeDef() to get the AttributeDef and then call any of its set...() methods. Here is an example:

Example:

   @Override
   public AttributeDef getAttributeDef(int attribIndex) {
        // check for some specific attribute
        if (attribIndex == SOME_ATTRIBUTE_INDEX) {
                //get the attribute's definition
               AttributeDef def = super.getAttributeDef(attribIndex);

               // conditionally update some attribute value
               // if (someCondition) {
               //((ViewAttributeDefImpl)def).set...()
               //}

               return def;
        }

        return super.getAttributeDef(attribIndex);
   }


Context:

View Object Implementation Class

Bit #25 - Hiding a View Criteria item based on some condition

You can hide or show a View Criteria item (i.e. a criterion), based on some business logic condition by calling setProperty() on an oracle.jbo.ViewCriteriaItem. The method accepts a ViewCriteriaItemHints parameter indicating the view criteria item property to set - in this case CRITERIA_RENDERED_MODE - and a second ViewCriteriaItemHints parameter indicating the property value - in this case any of the CRITERIA_RENDERED_MODE_BOTH, CRITERIA_RENDERED_MODE_BASIC, CRITERIA_RENDERED_MODE_ADVANCED, CRITERIA_RENDERED_MODE_NEVER, CRITERIA_RENDERED_MODE_DEFAULT. To hide or show a criterion, you will have to look for it by iterating through all the criteria rows and all the criteria items for each row. Once found, call setProperty() to set its render mode. Here is an example helper method that illustrates this case.

Example:

    /**
     * Hides a view criterion.
     * Example: The following will hide the SourcePolicyNbr criterio if the condition
     *          is true. If the condition is false, it will show the criterio in BOTH basic and
     *          advanced.
     *        
     *          hideCriteriaItem("SomeCriteria", "SomeCriteriaItem",
     *             someCondition==true, ViewCriteriaItemHints.CRITERIA_RENDERED_MODE_BOTH);
     *
     *
     * @param viewCriteriaName the view criteria name
     * @param criteriaItemName the criterio name
     * @param condition the HIDE condition
     * @param showHint the SHOW hint
     */
     protected void hideCriteriaItem(String viewCriteriaName,
                                    String criteriaItemName, boolean condition,
                                    String showHint) {
        if (viewCriteriaName != null) {
            ViewCriteria v = this.getViewCriteria(viewCriteriaName);
            if (v != null) {
                boolean found = false;
                while (v.hasNext() && !found) {
                    ViewCriteriaRow vcr = (ViewCriteriaRow)v.next();
                    if (vcr != null) {
                        ViewCriteriaItem[] vcis = vcr.getCriteriaItemArray();
                        if (vcis != null && vcis.length > 0) {
                            for (int j = 0; j < vcis.length && !found; j++) {
                                ViewCriteriaItem vci = vcis[j];
                                if (vci != null && criteriaItemName != null &&
                                    criteriaItemName.equals(vci.getName())) {
                                    found = true;
                                    vci.setProperty(ViewCriteriaItemHints.CRITERIA_RENDERED_MODE,
                                                    condition ?
                                                    ViewCriteriaItemHints.CRITERIA_RENDERED_MODE_NEVER :
                                                    showHint);
                                    v.saveState();
                                }
                            }
                        }
                    }
                }
            }
        }
    }


Context:

View Object Implementation Class

Bit #24 - Displaying Application Module Pool Statistics

You can display statistics related to your Application Module Pools by calling dumpPoolStatistics() on a oracle.jbo.common.ampool.ApplicationPool object. You can acquire an ApplicationPool object by calling getResourcePool() on a oracle.jbo.common.ampool.PoolMgr object and specifying the name of the application module pool name. So, how do you get a PoolMgr object? Just call the static PoolMgr.getInstance(). Finally, you can get the pool name by calling getResourcePoolKeys() on the PoolMgr and enumerating the pools managed by the pool manager. Here is an example:

Example:


    // helper to dump pool statistics to log
    private void dumpAMPoolStatistics() {
        // get the pool manager
        PoolMgr poolMgr = PoolMgr.getInstance();
        // get the pools managed
        Enumeration keys = poolMgr.getResourcePoolKeys();
        if (keys != null) {
            if (keys.hasMoreElements()) {
                // may manage many pools, we will get the name of first one managed
                String poolname = (String)keys.nextElement();
                System.out.println("AM pool name: " + poolname);
                // get the AM pool
                ApplicationPool pool =
                    (ApplicationPool)poolMgr.getResourcePool(poolname);
              
                // log AM pool diagnostics
                PrintWriter out = new PrintWriter(System.out, true);
                pool.dumpPoolStatistics(new PrintWriter(out));
                out.flush();
            }
        }
    }


The helper function above, when added to your application module will display - upon calling it, the AM statistics in the log window as it is shown below.

Context:

BC Implementation Class


References:
83. Dump Application Module Pooling Statistics Servlet

Bit #23 - Using findAndSetCurrentRowByKey() to set the View Object currency

You can set the currency on a View Object (VO) by calling its findAndSetCurrentRowByKey() method. The method accepts two arguments: a Key object that is used to locate the row in the VO and an integer indicating the range position of row (for VOs configured with Range Paging Access Mode). Below is an example. The example saves the VO currency, queries the VO and finally restores its currency. Click on the references below to get all the details on the example.

Example:

   /**
   * Helper to requery the view.
   */
   public void requery() {
      Row currentRow = getCurrentRow();
      Key currentRowKey = currentRow.getKey();
      int rangePosOfCurrentRow = getRangeIndexOf(currentRow);
      int rangeStartBeforeQuery = getRangeStart();
      executeQuery();
      setRangeStart(rangeStartBeforeQuery);
      findAndSetCurrentRowByKey(currentRowKey,rangePosOfCurrentRow);
}

Context

View Object Implementation Class
Application Module Implementation Class

References
http://radio-weblogs.com/0118231/2004/11/22.html

Bit #22 - Using getPostedAttribute() to determine the posted attribute's value

Call getPostedAttribute() anywhere in your Entity Object implementation class to retrieve the posted value of an Entity attribute. The example below calls getPostedAttribute() and getAttribute() to determine the attribute value in the database (posted) and in the Entity cache (not posted yet) respectively. They are called from within an overridden doDML(). Then based on the result of comparing them, certain business logic decisions can be made. Note that we call getPostedAttribute() before calling super.doDML(). This is done because calling super.doDML() will in effect post the attribute value in the Entity cache to the database, so will not make much sense to compare them afterwards: They will be the same!

Example:

    // in your Entity Object Implementation class

    @Override
    protected void doDML(int operation, TransactionEvent e) {

        final String EMPLOYEE_ID = "EmployeeId";
      
        // get posted value of EmployeeId attribute
        Object postedEmployeeId = getPostedAttribute(this.getAttributeIndexOf(EMPLOYEE_ID));
      
        // get value of EmployeeId before re-posting
        Object employeeId = this.getAttribute(EMPLOYEE_ID);
      
        // compare and take some action based on the results of comparison
        if (employeeId != null && employeeId.equals(postedEmployeeId)) {
          // do something here
        }
      
        // finally re-post by calling super.doDML()
        super.doDML(operation, e);
    }


Context

Entity Object Implementation Class

Bit #21 - Overriding prepareSession() to do session-specific initializations

You can override prepareSession() in your custom Application Module class to do session-specific initializations, such as invoking a stored procedure to initialize the database state for the specific user, store user information, set application-wide configuration parameters based on the user and so on. The framework invokes prepareSession() when the Application Module is first checked-out from the Application Module pool for a new user session.

Example:

     @Override
     protected void prepareSession(Session session) {

          super.prepareSession(session);

         // do session-specific initializations
     }


Context:

Application Module Implementation Class

Bit #20 - Overriding beforeCommit() to execute custom code before commit

Override the Application Module beforeCommit() method in your custom Application Module implementation class to execute any custom code that depends on data already posted to the database. Such code may include - but not limited to - validations done in the database via a stored procedure for example. The framework calls this method after doDML() which means that posted data are available but not yet committed.

Example:

// in your Application Module Implementation class

@Override
public void beforeCommit(TransactionEvent transactionEvent) {

        // call some stored procedure here

       super.beforeCommit(transactionEvent);
}


Context:

Application Module Implementation Class

Bit #19 - Downloading a file

Use an af:fileDownloadActionListener Rich Faces component to download data from the server to a client machine. Add the listener inside the component that will initiate the download, an af:commandButton for example, and specify the content type and the name of the file. Also specify a method in a backing bean that will be called to perform the download. In the backing bean method get the formated data to be saved from the model and use the supplied OutputStream to write the data.


Example:

In .jsf page:

<af:commandbutton id="buttonid"  " text="Download" ...
    <af:filedownloadactionlistener contenttype="application/octet-stream"
                method="#{backingBean.doDownload}"  filename="defaultFilename.txt"/>          
</af:commandButton>

In backing bean:

  public void doDownload(FacesContext facesContext, OutputStream outputStream) {
      // write the neccessary code to get the download data from the Model
      String data = getDownloadData();

      // save to the output stream
      try {
          OutputStreamWriter writer = new OutputStreamWriter(outputStream,"UTF-8");
           writer.write(data);
           writer.close();
          outputStream.close();
      } catch (IOException e) {
          // handle I/O exceptions
      }
  }


Context:

JSF Page
Backing Bean

Bit #18 - Dynamically changing the View Object's query WHERE clause

You can dynamically change the View Object's (VO) query WHERE clause by overriding the buildWhereClause() VO method. When doing so, ensure that you call the base class' buildWhereClause() first, to let the framework do its processing before making your own changes. The StringBuffer parameter that is passed to the method is the complete query SQL statement. Do your changes directly onto it. When done, make sure that you return appropriately a true/false boolean to indicate whether a WHERE clause was appended to the query or not. Here is an example.

Example:


    @Override
    protected boolean buildWhereClause(StringBuffer sqlBuffer, int noBindVars) {

        // call ViewObjectImpl's buildWhereClause() to allow the framework to do its processing
        boolean hasWhereClause = super.buildWhereClause(sqlBuffer, noBindVars);

        if (hasWhereClause) { // framework added a WHERE clause
            // modify the WHERE clause as needed
        }
        else { // framework did not add a WHERE clause, so we need to add it ourselves
            // add a WHERE clause here
            hasWhereClause = true; // ensure that is set to notify the framework
        }

        return hasWhereClause; // return true/false to indicate whether a WHERE clause was added
    }


Context:

View Object Implementation

Bit #17 - Using the securityContext bean in a JSF page

To acess the user's authentication information from within a JSF page, use the securityContext bean and any of its available methods. For instance, using Expression Language (EL), the following will return true/false indicating whether the user is authenticated or not: #{securityContext.authenticated}. Similarly, to determine whether the user has been assigned a specific role, use the following EL snippet #{securityContext.userInRole['SomeRole']}. It will return true if the user has been assigned the specific role.


Example:

    // in the context of a JSF page

    <af:commandLink id="login_logout" action = "#{securityContext.authenticated ? 'logout' : 'login'}" text="#{securityContext.authenticated ? 'Logout' : 'Login'}/>

    <af:commandToolbarButton id="delete"  actionListener="#{backingBean.delete}" disabled="#{securityContext.userInRole['CanDelete']==false}" text="Delete"/>


Context:

JSF Page

Bit #16 - Removing a row from a query collection without deleting it from the database

There are times when you want to remove a row from a query collection (the query result) without actually removing it from the database. The query collection - oracle.jbo.server.QueryCollection - gets popullated each time the View is executed - when the View's associated query is run, and represents the query result. While the Row.remove() will remove the query collection row it will also remove the underlying Entity row - for an Entity-based View - and post a deletion to the database. If your programming task requires that the row is removed from the query collection only, i.e. removing a table row in the UI without actually posting a delete to the database, use the Row method removeFromCollection() instead. Just be aware that each time the View is re-executed the Row will show up once again!

Example:

        // in the context of the ApplModuleImpl

        // remove the current row from the query collection
        EmployeesRowImpl employee = (EmployeesRowImpl)(this.getEmployees().getCurrentRow());
        employee.removeFromCollection();

        // the employee row has been removed from the result set and cannot be used anymore


Context:

Application Module Implementation Class
View Object Implementation Class

Bit #15 - Using a Key to locate a Row in a View Object, Pt. 2

Instead of using the findByKey() method to locate a number of rows in the View Object identified by a Key attribute - explained in Bit #14 - Using a Key to locate a Row in a View Object, you can use the View Object getRow() method supplying the Key as an argument. This method will return the Row identified by the Key supplied as an argument to it. An example follows.

Example:

    // in the context of the ApplModuleImpl

    // locate the employee's department
    Number departmentId =
        ((EmployeesRowImpl)(this.getEmployees().getCurrentRow())).getDepartmentId();
    Key keyDepartment = new Key(new Object[] { departmentId });

    // get the department based on the department identifier
    DepartmentsRowImpl department =
        (DepartmentsRowImpl)this.getDepartments().getRow(keyDepartment);

    if (department != null) {
        // you can access the Department's attributes here....
    }



Context:

Application Module Implementation Class
View Object Implementation Class

Bit #14 - Using a Key to locate a Row in a View Object

Instead of iterating a View Object using a RowSetIterator - as described in Bit #4 - Iterating a View Object using a secondary RowSetIterator, you can locate a row directly using the ViewObject method findByKey(). This will work as long as you indicate a View Object attribute as a Key Attribute. To use this method, you will need to first instantiate a jbo.Key object and then pass it as an argument to findByKey(). findByKey() will return an array of rows that match the Key object. Special attention should be given when constructing Key objects for multi-part keys and for View Objects that are based on more than one Entity Objects. These cases are explained in detail in the Oracle Fusion Middleware Java API Reference for Oracle ADF Model documentation referenced below.

Example:

        // in the context of the ApplModuleImpl
      
        // locate the employee's department
        Number departmentId =
            ((EmployeesRowImpl)(this.getEmployees().getCurrentRow())).getDepartmentId();
        Key keyDepartment = new Key(new Object[] { departmentId });
      
        // the second argument indicates the maximum number of rows to return
        Row[] departments = this.getDepartments().findByKey(keyDepartment, 1);
        if (departments != null && departments.length > 0) {
            DepartmentsRowImpl department = (DepartmentsRowImpl)departments[0];
          
            // you can access the Department's attributes here....
        }

Context:

Application Module Implementation Class

View Object Implementation Class

Reference:

Oracle Fusion Middleware Java API Reference for Oracle ADF Model, findByKey

Bit #13 - Overriding create() to set the default value for a View Row attribute

One way to set the default value for a View Row attribute is to override its create() method in your custom View Row Implementation and call the attribute setter method to set its default value. Calling the attribute setter from inside the overridden create() method does not mark the new row as changed and it behaves like declaratively assigning a default value for the attribute. An example follows.

Example:

    @Override
    protected void create(AttributeList attributeList) {

        super.create(attributeList);

        // set main company's telephone number as default
        this.setPhoneNumber("6145551212");
    }


Context:

View Object Row Implementation

Bit #12 - Accessing the authenticated user's security roles from a backing bean

To access the authenticated user's security roles from a backing bean, first retrieve the SecurityContext from the current ADFContext instance and then call its getUserRoles() method. getUserRoles() returns a String array of all the roles defined for the user. To determine whether a specific role is assigned to the user, call the  SecurityContext  isUserInRole() method specifying the role as an argument. This method will return a boolean indicator of whether the role is assigned to the user or not.


Example:

    // in the context of a backing bean

    public String[] getUserRoles(){
        return ADFContext.getCurrent().getSecurityContext().getUserRoles();
    }

    public boolean isUserInRole(){
        return ADFContext.getCurrent().getSecurityContext().isUserInRole("RoleName");
    }


Context:

Backing Bean


Reference:

Oracle Fusion Middleware Java API Reference for Oracle ADF Share, getUserRoles

Bit #11 - Accessing an object stored at the PageFlowScope from a backing bean

You can access the PageFlowScope from a backing bean, by getting the AdfFacesContext instance and calling its getPageFlowScope() method. This will return the Map of all objects stored in the PageFlowScope. To retrieve a specific object, call get() on the Map specifying the object identifier. Similarly, call the getViewScope() and getProcessScope() methods of the AdfFacesContext to retrieve the ViewScope and ProcessScope respectively.

Example:

        // in the context of a backing bean
        Object data = AdfFacesContext.getCurrentInstance().getPageFlowScope().get("objectID");


Context:

Backing Bean


Reference:

Oracle Fusion Middleware Java API Reference for Oracle ADF Faces, getPageFlowScope

Bit #10 - Selectively enabling Partial Page Rendering programmatically

You can selectively enable Partial Page Rendering (PPR) programmatically from a backing bean, by calling the AdfFacesContext method addPartialTarget(). To do so, simply bind the target component to the backing bean, get the AdfFacesContext  and call its addPartialTarget() method passing the bound component as a parameter. This will in effect rerender the component. The advantage of calling addPartialTarget() is that it will rerender the component selectively for the specific events that you choose.

Example:

    // in the context of the backing bean

    // bind the component to the backing bean
    private RichPanelBox panel;

    public void setPanel(RichPanelBox panel) {
        this.panel = panel;
    }

    public RichPanelBox getPanel() {
        return panel;
    }

    // rerender the component
    private void rerenderComponent() {
        AdfFacesContext.getCurrentInstance().addPartialTarget(this.panel);
    }

Context:

Backing Bean

Reference:

Oracle Fusion Middleware Java API Reference for Oracle ADF Faces, addPartialTarget

Bit #9 - Controlling the updatability of View Object attributes programmatically

The updatability of a View Object attribute can be controlled programmatically via the isAttributeUpdateable() method. When you look at its documentation, the declarative precedence that determines the attribute updatability should become clear. Programmatically, you override this method in your View Object Implementation Java file that you generate declaratively in JDeveloper. isAttributeUpdateable() is called for each attribute in the View Object. The index that is passed as an argument to the method determines the attribute index as it is returned by the AttributesEnum enumeration - defined in the View Object Implementation source - for the specific attribute. To indicate that the specific attribute is updateable, isAttributeUpdateable() returns true; it returns false otherwise.

Example:

    @Override
    public boolean isAttributeUpdateable(int index) {
        boolean isUpdateable = super.isAttributeUpdateable(index);
        
        // do not allow updating first and last name
        if (index == FIRSTNAME || index == LASTNAME) {
            isUpdateable = false;
        }
        
        return isUpdateable;
    }

Context:

View Object Row Implementation

Reference:

Oracle Fusion Middleware Java API Reference for Oracle ADF Model, Row Interface

Bit #8 - Executing an operation binding programmatically from a backing bean

To access an OperationBinding in a backing bean, call getOperationBinding() on the DCBindingContainer - the data control binding container - and specify the operation binding identifier that you assigned to the operation during the declarative binding process. Once you have the OperationBinding call its execute() method to execute it. If you need to pass any arguments to the operation, call getParamsMap() to get the operation parameters map and put() on the map the specific argument. Call getResult() after the call to execute() to retrieve the result of the execution. Here is an example.


Example:

        // in the context of a backing bean

         OperationBinding operation = bindings.getOperationBinding("operation_name");

         operation.getParamsMap().put("parameter_name", parameterValue);

         operation.execute();

         if (operation.getResult() != null) {
                  Boolean result = (Boolean) operation.getResult(); // cast to the expected result type
        }

Context:

Backing Bean

Bit #7 - Reseting the View Criteria associated with a View Object

To reset the View Criteria defined for a specific View Object, first you will need to retrieve the View Criteria from the View Object. You do this by calling the View Object method getViewCriteria() specifying the name of the View Criteria. This method will return a ViewCriteria object. Proceed with removing the criteria from the View Object by calling removeViewCriteria() on it. Call resetCriteria() on the ViewCriteria to reset them and finally re-apply the criteria to the View Object by calling applyViewCriteria() on it. Here is an example.

Example:

        // in the context of the Application Module Implementation

        ViewObjectImpl vo = this.getSomeViewObject();

        ViewCriteria vc = vo.getViewCriteria("criteria_name");
        vo.removeViewCriteria("criteria_name");

        vc.resetCriteria();
        vo.applyViewCriteria(vc);

Context:

Application Module Implementation
View Object Implementation

Bit #6 - Removing all rows from a View Object

To remove all rows from a View Object programmatically - i.e. clear or reset the View Object, call its executeEmptyRowSet() method. You can do this anywhere in the context of the Application Module or View Object Implementation.

Example:

    // in the context of the Application Module Implementation

   ViewObjectImpl vo = this.getSomeViewObject();
   vo.executeEmptyRowSet();


Context:

Application Module Implementation
View Object Implementation


Reference:

What Does executeEmptyRowSet() Do?

Bit #5 - Accessing a resource bundle from a backing bean

You can access a resource bundle from a backing by calling the getResourceBundle() method on a javax.faces.application.Application object and specifying the bundle name. You get the Application object by calling getApplication() on the FacesContext. The getResourceBundle() returns a ResourceBundle object. To get some resource data from the bundle, call getString() on the ResourceBundle specifying the resource identifier. The example below illustrates the case.

Example:


        FacesContext fc = FacesContext.getCurrentInstance();
        ResourceBundle bundle = fc.getApplication().getResourceBundle(fc,"bundle_name");
        bundle.getString("resource_identifier");

Context:

Resource Bundle
Backing Bean

Bit #4 - Iterating a View Object using a secondary RowSetIterator

The recommended way to iterate a View Object is via a secondary RowSetIterator returned after calling createRowSetIterator() on the View Object. It is suggested to call reset() on the RowSetIterator before iterating it. This will move the currency to the slot before the first row. Iterate while calling hasNext() to check for next row availability and subsequently by calling next() to get the next row. When done, call closeRowSetIterator() to close the row set iterator. Failure to use a secondary RowSetIterator when directly iterating the View Object, could lead to end user confusion as the row set currency changes affecting the user interface.

Example:

// in the context of the AppModuleImpl

       RowSetIterator iterator = viewObject.createRowSetIterator(null);
       
       iterator.reset();

while (iterator.hasNext()) {
   Row row = iterator.next();
 
// process the row here
}

iterator.closeRowSetIterator();

Context:

Application Module Implementation class
View Object Implementation class


Reference:

Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1) Part Number B31974-05 [Section 9.7.6 What You May Need to Know About Programmatic Row Set Iteration]

Bit #3 - Adding Javascript to a JSPX page

The recommended way to add scripting to your JSPX page is via the metaContainer <facet> tag. You add the metaContainer <facet> within the <af:document> tag. You can group your scripts within the metaContainer <facet> using an <af:group> tag. The actual script should be added within an <afh:script> or a <trh:script> tag. Adding Javascript to your JSPX page by directly placing a <script> tag is not recommended because it could have undesired side effects related to the proper resizing of the components in the page.

Example:

<f:facet name="metaContainer">
    <af:group>
        <afh:script source="/js/YourJsLibrary.js"/>
        <afh:script>

           function someFunction()

           {

                 …

           }

        </afh:script>

    </af:group>

</f:facet>

Context:

JSPX Page

Bit #2 - Setting a bind variable value programmatically

To set the value of a bind variable programmatically, you will need to first get the View Object where the bind variable is defined. Then from the View Object you need to get access to the VariableValueManager via the call ensureVariableManager(). Finally you need to call setVariableValue() on the VariableValueManager to set the bind variable to a specific value. Once all these are done, execute the View Object query with the new bind variable value by calling executeQuery()  on the view as shown below.

Example:

        ViewObjectImpl view = this.getSomeView();
        VariableValueManager vm = view.ensureVariableManager();
        vm.setVariableValue("bindVariableName", value);

        view.executeQuery();

Context:

Application Module Implementation class
View Object Implementation class

Bit #1 - Adding Javascript to a template definition

The proper way to add scripting to a template definition is to add it in a <af:resource> tag of type javascript. This tag resides anywhere inside the template defition tag <af:pageTemplateDef>. Adding scripting to the template definition in any other way, for example by placing it inside a <script> tag, will produce undesired effects related to resizing of components within the template.

Example:

  <af:pageTemplateDef var="attrs" id="someId">
      <af:form id="formid">
          ...
      </af:form>
      <af:xmlContent>
         ...
      </af:xmlContent>
       <af:resource type="javascript">      
            function someFunction()
           {
               ...
           }   
      </af:resource>
  </af:pageTemplateDef>

Context:

Template Definition JSPX

Reference:
Oracle® Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1) Part Number B31973-04 [Section 19.5 Adding Resources to Pages]