31 May 2014

Sometimes we need to access the business service layer in a task flow finalizer. For example, in order to clean up some resources we have to invoke an application module method in a finalizer. But a task flow finalizer is not an activity, therefore it can't have its own page definition file and we are not able to use the bindings layer in order to invoke the application module method. So, we have to get a reference to the application module instance and work with its methods directly. That's not really cool. This is kind of a rule violation. Let's see what we can do about that.

We're going to manually create a page definition file for the task flow finalizer and we are going to access the binding container in the finalizer method programmatically. So, in order to create a page def file we are going to drag-n-drop the AM method to the task flow diagram as a method call:

Jdeveloper is going to create a page def file for the method call and it's going to register the page def file in the DataBindings.cpx. So, in the DataBindings.cpx we'll have a page map:

27 May 2014

In one of my previous posts I explained what happens behind the scene while working with View Accessors. Usually
we define view accessors in the same view object definition where we
define lists of values. However, it is also possible to define view accessors at the entity definition level. In that case we can use an entity level view accessor when defining lists of values in the entity based view objects. This is a pretty convenient feature in terms of reusing. So, a proper view accessor can be defined only once at the entity definition level and it’s going to be available for reusing in all view objects that are based on this entity definition.
But besides convenience, this feature can also be useful in terms of performance. For each view accessor definition the framework at runtime creates an
internal lookup VO instance according to the view definition linked to
the view accessor. This is shown on the following diagram.

There are two VO definitions on the diagram - VO1 and VO2. Both of them are based on the same entity definition. There are three view accessors on the diagram. Two of them are defined at the view object definition level and the rest one is defined at the entity definition level. All view accessors point to the same lookup view object definition. The framework at runtime is going to create three internal view object instances. One instance per view accessor definition. Note, that lists of values that are based on the entity level view accessor will share the same lookup view object instance, which means they are going to reuse the same query results and share the same query collection cache.
So, view accessors, defined at the entity level can be considered by ADF developers as a promising technique.