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.
