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.