There is a common belief among ADF developers that setting the iterator binding change event policy to ppr is not a good thing in terms of performance because this policy forces the framework to refresh all attribute bindings that are bound to this iterator on each request. That's not true!
The framework refreshes only attributes that have been changed during the request and attributes that depend on the changed attributes.
Let's consider a simple use-case. There is a form:
The iterator's change event policy is set to ppr, which is default in JDeveloper 11gR2 and 12c. The "First Name" and the "Last Name" fields are auto-submitted. The "Full Name" field is going to be calculated by concatenation of the first and last names. So, in the setters of the first and last names we have a corresponding method call:
In response to the modified last name the framework is going to partially refresh only two input components - the last name and the full name. The full name is going to be refreshed because its value has been changed during the request. The rest of the components on the form don't participate in the partial request.
Let's consider a bit more complicated use case.
We are going to show value of the "Title" field as a label of the "Full Name" field on the form:
Despite the value of the "Full Name" has not been changed during the request the input component is going to be refreshed because its label property points to the value of a changed field. And again only these two fields are going to be refreshed during the partial request.
That's it!
The framework refreshes only attributes that have been changed during the request and attributes that depend on the changed attributes.
Let's consider a simple use-case. There is a form:
The iterator's change event policy is set to ppr, which is default in JDeveloper 11gR2 and 12c. The "First Name" and the "Last Name" fields are auto-submitted. The "Full Name" field is going to be calculated by concatenation of the first and last names. So, in the setters of the first and last names we have a corresponding method call:
public void setLastname(String value) { setAttributeInternal(LASTNAME, value); setFullname(getFirstname() + " " + getLastname()); }Let's have a look at the response content generated by the framework once the "Last Name" has been inputted:
In response to the modified last name the framework is going to partially refresh only two input components - the last name and the full name. The full name is going to be refreshed because its value has been changed during the request. The rest of the components on the form don't participate in the partial request.
Let's consider a bit more complicated use case.
We are going to show value of the "Title" field as a label of the "Full Name" field on the form:
<af:inputText label="#{bindings.Title.inputValue}" value="#{bindings.Fullname.inputValue}" required="#{bindings.Fullname.hints.mandatory}" columns="#{bindings.Fullname.hints.displayWidth}" maximumLength="#{bindings.Fullname.hints.precision}" shortDesc="#{bindings.Fullname.hints.tooltip}" id="itFullName"> </af:inputText>So, the label of the "Full Name" should be updated every time we make a selection of the title. For sure, the "Title" field is auto-submitted. And let's have a look at the response content:
Despite the value of the "Full Name" has not been changed during the request the input component is going to be refreshed because its label property points to the value of a changed field. And again only these two fields are going to be refreshed during the partial request.
That's it!
No comments:
Post a Comment
Post Comment