Sunday, February 24, 2013

Ordering of Executable Bindings


Consider the following scenario for ExecuteWithParam:



Here, executeWithParam is used to execute EmployeeVO having a VC with a bind variable for FirstName, as shown below:



Since a bind variable is there so ExecuteWithParam method will be visible in the DC section. As shown in the page definition above, the Employee table is dropped as a form and hence an iteratorBinding, EmployeeVO3Iterator, is created for it. A VC is assigned with the EmployeeVO3 VO instance to use the bind variable, as shown below:



And the actionBindng ExecuteWithParams is assigned a static value for the only bind variable as shown below:



Here is the data in the database:



And here the expected output:



This blog is to share the findings of how Refresh condition of invokeAction executable binding can influence the output. Consider the following scenario where the invokeAction is defined after the iteratorBinding, as shown below:



After placing the debug point on invokeAction executable binding, I tried to understand what happens when the Refresh condition is modified with different values. And here is the result summary:

Scenarion: InvokeAction after Iterator Binding and Refresh = deferred
Result: The executable binding debug is not even called, and the first row with first name, Steven, is shown in the table.

Scenarion: InvokeAction after Iterator Binding and Refresh = ifNeeded
Result: The output came as expected, the record with first name as Lalit, but the invokeAction executable binding is called twice.

Scenarion: InvokeAction after Iterator Binding and Refresh = never
Result: Same as scenario 1. The executable binding debug is not even called, and the first row with first name, Steven, is shown in the table.

Scenarion: InvokeAction after Iterator Binding and Refresh = prepareModel
Result: Perfect! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once.

Scenarion: InvokeAction after Iterator Binding and Refresh = prepareModelIfNeeded
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once.

Scenarion: InvokeAction after Iterator Binding and Refresh = RefreshAfter
Not Covered Here.

Scenarion: InvokeAction after Iterator Binding and Refresh = renderModel
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once.

Scenarion: InvokeAction after Iterator Binding and Refresh = renderModelIfNeeded
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once.

Now let’s try to see what happens when we put the invokeAction executable binding above the iterator binding:



Scenarion: InvokeAction before Iterator Binding and Refresh = deferred
Result: The executable binding debug is not even called, and the first row with first name, Steven, is shown in the table. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = ifNeeded
Result: The output came as expected, the record with first name as Lalit, but the invokeAction executable binding is called twice. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = never
Result: Same as scenario 1. The executable binding debug is not even called, and the first row with first name, Steven, is shown in the table. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = prepareModel
Result: Perferct! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = prepareModelIfNeeded
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = renderModel
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once. This result is same as after case.

Scenarion: InvokeAction before Iterator Binding and Refresh = renderModelIfNeeded
Result: Perferct Again! The output came as expected, the record with first name as Lalit, and the invokeAction executable binding is called only once. This result is same as after case.

So, iteratorBinding and invokeAction binding in the executable section have no bearing as far as ordering is concerned.