Oracle Application Framework

In this article, I would like to explain the different levels at which defaulting can take place in OA Framework.
There are instances when you try to default a value into a field in OA Framework page,
but you may notice that defaulting just does not take effect.
Hence it becomes important to understand the defaulting concept/architecture in OA Framework.
In a nutshell, there are at least 8 levels at which defaults can take place into an OA Framework screen.

 

Many people state that “we must never extend a controller”. But I find hard to be convinced by that statement.
There are various examples where Controller extension becomes mandatory. Sure there may be risks in extending
controller, but the truth is that it could be SAFER to extend a controller than extending a
View Object [ in cases where a view object being extended was built by Oracle in Expert Mode].
In this example, you will see yet another example of scenarios where controller extension becomes useful.


Read this link to see how you can keep your controller extensions upgrade safe.
Article that discusses keeping your controller extensions safe
Oracle lets you extend the controller, and that too at all admin-personalizable levels.


Now, lets take a classic business scenario
You wish to override the default value in some field in an OA Framework Page.
However you notice that default value specified in Personalization is not working.


To explain the reason, I would like to explain the scenarios under which this can happen.
Lets see the possible places where you can specify a default value into a field.


First, lets have a look at how data from a table becomes visible in the screen.
There are various layers through which data travels before becoming visible to the end user in screen.


This picture will explain the data flow, assuming the ViewObject of the screen is based on Entity Object.



Above what you see is a very simplistic view of how data travels from a table to screen.

However, in reality, the total list of layers is shown below, which primarily includes the SubLayers within the page.
Following factors influence which value becomes visible on a page

• How the original page was built
• What personalizations have been done to the page
• If anything in processRequest method controller class influences what you see on the page

Hence, the real number of layers, where data can be default, when a new record is created is shown below….



As you can see above, controller has the final say.
After controller, the next preference goes to Personalization.
Also, it is important to note that Defaulting at Entity Object level gets the least priority.


You will also notice that there are 5 possible levels at which defaults can take place, one of which is Personalization.
However, personalizations can be applied at various levels too, hence further increasing the number of layers at which defaults take place.



So, lets take some Q&A
Question:- I wish to default a value into a a field, in all the screens that derive their data from a same <table>.<column>
Answer :- In this case, you need to extend Entity Object.
However please note that, you might have to move your default logic up in the layer, in case Entity Object level defaulting does not take effect.
However, extension of Entity Object is the preferred approach in this case.


Question:- I notice that Oracle’s default kick off from View Object attribute level. I need to overwrite that default with my own default
Answer :- In this case, you can extend that view object. Alternately, you can traverse up the ladder, and do your defaulting in Personalization itself.
Note:- To choose between personalization and VO Extension, first find out if your custom defaulting should work across all the screens
based on this view object. If your custom default should work against merely one screen, then prefer using personalization.


Question:- I have defaulted value into a field using personalization. But it is not taking effect. What should I do, in order to get my custom defaulting logic to work?
Answer:- In this case, you will discover that Oracle’s default logic resides within the Controller against that page.
Hence you will have to extend that Controller, so as to override your custom defaulting logic.
Alternate approach is to find out how Oracle’s default works i,e, if Oracle’s controller uses a ViewObject to fetch
default value, then you can extend that VO itself. However, VO extension will impact all the references to that VO,
hence CO Extension is a safer and much solid approach in this case.

Add comment

Name (required)

E-mail (required, but will not display)

Website

Notify me of follow-up comments

Refresh

Send

Cancel