What happens when a View Object is Executed ?

I am sure you would learn something new from this blog , thats the main intention of this blog 

What are View Objects : 

 

   View Objects are the  business components  that collect data from data source and the data can be modified/shape the data accordingly.

 

   Their are two types of View Objects :

One is Read-Only and the other is Updatable ViewObject which is based on Entity Object . 

 

 Lets us see the internal architectural understanding of View Object and what happens when we execute a query : 

 

     Internally before the view object hits the data source , it goes through few other stages which are as follows : 

 

   RowSets :  VO uses a special data structure known as RowSet to manage the collection of rows from a query on data source(Database). It has a default rowset or primary rowset ,So when ever for the first time if we execute the VO it first hits the default rowset.  

                    

Example : Lets us take a VO based on a query where it has a bind variable as DEPTID. So the query can have a bind vairable and each time you pass a value lets say DEPTID=10 

and again we pass DEPTID =20 . So each time you pass a variable it stores them in a rowset . If they already have a same rowset , it will consider the same rowset instead of creating new one . For example if DEPTID =10 is already their as rowset , it will consider the same instead of creating new one . 

 

  

Query Collection : 

   

   Query Collection is mainly used for caching the result of the executed query VO . A VO can have multiple query collections depending on the rowsets.

 

Example : If we have 2 rowsets where DEPTID =10 and DEPTID=20 . So the results of the executed VO with these bind variables are stored in Query Collection .

 

  

Now we understood what are the other layers that are to be used before hitting the data source . Now let us see how will it be executed with a example : 

 

 Example :  Lets consider a java code snippet where we execute a vo and retrieve the values 

     

          ViewObject vo = ApplicationModule.findViewObject(“EmployeesVO”);

           vo.executeQuery(); 

           Row row = vo.first();                                          // gets the first row

 

    Steps involved in excuting this VO are as follows : 

 

 

1) ADF client starts interaction with the Application Module .

 

2) ADF Client looks for the requested View Object (EmployeesVO) instance in AM.

 

3) Now before executing the VO , it does as below  : 

       a) Checks for revelant Query Collection for Search Parameters (Bind Varibles ) ,                 If available uses the existing querycollection.

       b) If not present created a new Query Collection based on the Search                                 Parameters.

  

4) Once the QC is initialized , the new Rowset instance calls the                                           prepareRowSetQuery() on VO . This is used for placing your customcode before           Querycollection . (Eg: the Query for the rowset with the bind variable ) 

 

5) This is followed by executeQueryForCollection() , which delegates the call for                query collection instance and JDBC call for particular Database . 

 

6) Now when a client tries to get the first row in result set by calling first() , as the            result set retrieves the first row it displays the first row .

 

What if the ViewObject is Based on Entity Object ?

 

  When the ViewObject is based on EO , an entity Instance will be created  and added to corresponding entity cache. 

 

Hope this helps ….. 

 

     

Partial Page Rendering in ADF

PPR is of 2 types :

Partial Submit :

Components such as command buttons , command links etc.. have Partial Submit . If that is set to true ,upon an action it doesn’t refresh the whole page instead submits a form without a page to refresh .

Few of the other components like af:selectOneChoice works with this behaviour when we set autoSubmit to true. Partial Submit may also be triggered by components such as dialog boxes which refreshes only their child components .

Partial Refresh :

ADF components have partialTriggers attribute that developers use to refresh based on the other component id  added into the partialTrigger attribute.

Example :

<af:selectBooleanCheckBox id=”sb1”  partialTriggers = “db1” value=”#{ManagedBean.getValue}”/>

<af:commandButton text =”Submit” partialSubmit=”true” id = “db1”/>

Here in the above example if we see a command button has partialSubmit is set to true and then the id of the command button is used in selectBooleanCheckBox for partialTriggers  .

PPR Event in Java Programmatically :

Some times we might need to trigger the partial refresh of a component dynamically . For this we might need to go for PPR Event Programmatically .

AdfFacesContext.getCurrentInstance().addPartialTarget(<component>);

Here the <component > would be the binding that is defined for a component in a managed bean.

Limitations : 

The PPR concept cannot be used to change the rendered attribute of a component . So if we need to perform PPR on rendered component it should be done on the parent component level.

For Example : The parent component could be af:form , af:panelGroupLayout , af:panelFormLayout…etc.. The reason is that the rendered property is for the model level retrieving of data , so a single attribute cannot be filtered for partial submit.

Conceptual understanding of LifeCycle based on PPR Concept :

As ADF lifecycle is extended on JSF LifeCycle and in JSF lifecycle we doesnt have parial Submit Property  and instead the whole form is submitted to the server upon an action on a button. Internally for ADF components , to avoid the evaluation and update of all form fields during ADF LifeCycle , immediate is set to true for parent component.

Technically the optimized lifecycle uses defined event roots to determine the scope of an update .An event root describes the outermost boundaries in which the fields are validated on the client and for which the server side lifecycle is executed.

 

Hope this helps .

Hope this Helps !!!

On PageLoad Conceptual Understanding with Example

Phase Listeners : 

What are phase listeners  ? 

    A phase listener is a java class that is configured in faces-config.xml file . Its main intension is to monitor the Life Cycle. We can use custom phase listeners for modify the functionality or respond to the life cycle phases accordingly . 

Phase listener can be applied globally or to a particular page . 

Global Phase Listener :

 Skeleton of Global Phase Listener :

public class AdfInteractivePhaseListener implements PhaseListener {

// constructor :

               public AdfInterativePhaseListener() {

                }

// After a particular Phase is completed we can call this method to execute this method  application.

                 public void afterPhase(){

                       // your code

                  }

// Before a particular Phase is initialized we can call this method to execute your  application

                  public void beforePhase() {

                      // your code :

                    }

//   PhaseId out come determines the phase or phases that the custom listener method executes.

                       public PhaseId  getPhaseId(){

                       return PhaseId.ANY_PHASE;

                         }

}  

Local Phase Listener :

We mostly use the local phase listener  in page level. It is a java method that takes the PhaseEvent argument and that is referenced from f:view root element  in a page.

It receives all the phases notifications .To create this phase listener method , select the f:view tag in a page source and go to the property inspector and click on the BeforePhase or AfterPhase property fields and edit to create a new phase listener method in a managed bean.

The generated method in the managed bean looks as below : 

public void beforePhaseListener(PhaseEvent  phaseEvent) {

// Add your code

}

 public void afterPhaseListener(PhaseEvent phaseEvent){

//Add your code here

}

Here calling the getPhaseId on the PhaseEvent argument allows the developers to detect the current Life Cycle Phase for the page to respond.

Below is a example on how can we use this :

 Lets say you wanted to execute your code before Update Model Phase , Here is the approach for it :

public void beforePhaseListener(PhaseEvent  phaseEvent) {

if(phaseEvent.getPhaseId() == PhaseId.UPDATE_MODEL_VALUES){

System.out.println(“In the Update Model Phase”);

}

}

Hope this helps how to execute on pageload.

 

Life Cycle Of ADF with Example

In the below example I have a form with a HireDate input text and a submit button :                                                                                 

In ADF Life cycle , when a request is sent from client to Server  :

1. Restore View: The request  from a page is passed to bindingContext, which finds the page definition file that matches the URL. All the component tags, event handlers, converters, and validators on the submitted page have access to theFacesContext instance.
2. Initialize Context : BindingContainer object which is the runtime representation of the page definition is initialized.LifecycleContext object which stores the information about ADF lifecycle is initialized with the values of associated request, binding container.
3. Prepare Model: BindingContainer object prepares the page parameters.This phase prepares and evaluates any page or task flow parameters and refreshes application executables.
4. Apply Input Values :What ever the values you entered in the input text (HireDate as in our example ) gets stored in a temporary location  and initialized. Most associated events(like action events and value change events ..etc .. ) are queued for later processing.
5. Process Validations:Local values of components are converted from the input type to the underlying data type.In our example lets say we entered the text value as ’24-Aug-2013’ . This value is stored in Temporary location in Apply input values phase . Now the local value is which is by default in String format is converted to the underlying datatype format. In this example we have input text component data type as Date datatype (HireDate), so the string is converted into Date datatype and validated.If the converter fails, this phase continues to completion (all remaining converters, validators, and required checks are run), but at completion, the lifecycle jumps to the Render Response phase.If the converter validation is successful it will move to the Update Model Phase .
6. Update Model Phase :The component values are updated in the model and local values are discarded.
7. Validate Model Updates:In this phase the updated attribute value is validated even in the entity level where we can define our validation at entity level . If the validation is successful it will move to the Invoke Application phase.
8. Invoke Application :In this phase the Action events are triggered and  is passed to the Render response phase.
9. Render response :The page is built during this phase.

Hope this helps !!!!!!!!

Inspired to Blog new technologies and Human Values…….