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