Popup, Dialog and Input Components

In this post I would like to focus on a very common use case when we have af:popup containing af:dialog with input components inside. There are a couple of pitfalls that we need to watch out for when implementing this use case.
Let's consider a simple example:

<af:popup id="p1" contentDelivery="lazyUncached">
          
  <af:dialog id="d2" title="Dialog" >
     <af:inputText value="#{TheBean.firstName}" label="First Name" id="it1"/>
     <af:inputText value="#{TheBean.lastName}" label="Last Name" id="it2"/>
  </af:dialog>
  
</af:popup>  

The most interesting thing here is the popup's property contentDelivery which is set to lazyUncached. This prevents the popup from caching the submitted input values and forces it to get the values from the model on each request instead of using values from the cache.

Let's make the example a bit more complicated. In the lastName's  setter we are going to throw an exception:

public void setLastName(String lastName) throws Exception {        
    this.lastName = lastName;        
    throw new Exception("This last name is bad");
}

So, obviously if we try to submit the dialog we'll get the following:

The input values can not be submitted to the model and they are going to be stored in the local values of the input components. These local values are not going to be cleaned up even if we press the Cancel button and these values will be used during the subsequence request. In order to prevent this behavior we have to set resetEditableValues property of the popup to whenCanceled. Like this:

<af:popup id="p1" contentDelivery="lazyUncached"
                  resetEditableValues="whenCanceled">

  <af:dialog id="d2" title="Dialog" >
     <af:inputText value="#{TheBean.firstName}" label="First Name" id="it1"/>
     <af:inputText value="#{TheBean.lastName}" label="Last Name" id="it2"/>
  </af:dialog>  
  
</af:popup>  

Let's consider an example of af:dialog with custom buttons:

<af:popup id="p1" contentDelivery="lazyUncached"
                  resetEditableValues="whenCanceled"
                  binding="#{TheBean.popup}">

  <af:dialog id="d2" title="Dialog" type="none">
     <af:inputText value="#{TheBean.firstName}" label="First Name" id="it1"/>
     <af:inputText value="#{TheBean.lastName}" label="Last Name" id="it2"/>
     <f:facet name="buttonBar">
        <af:panelGroupLayout layout="horizontal" id="pgl1">
          <af:button text="Ok" id="b2" 
                     actionListener="#{TheBean.buttonActionListener}"/>
          <af:button text="Cancel" id="b3" immediate="true"
                     actionListener="#{TheBean.buttonActionListener}"/>
        </af:panelGroupLayout>  
     </f:facet>

  </af:dialog>  
  
</af:popup>  

So, there are two custom buttons "Ok" and "Cancel" with the following actionListener:

public void buttonActionListener(ActionEvent actionEvent) {
    getPopup().hide();
}

The resetEditableValues doesn't work in this case and local values of the input components won't be cleaned up when pressing the Cancel button. There are a couple of options to fix this issue.
The first one is to add af:resetListener to the Cancel button:

          <af:button text="Cancel" id="b3" immediate="true"
                     actionListener="#{TheBean.buttonActionListener}">
               <af:resetListener type="action"/>
          </af:button>           

The second option is to cancel the popup instead of just hiding it in the Cancel button action listener:

  <af:button text="Ok" id="b2" 
             actionListener="#{TheBean.buttonActionListener}"/>
  <af:button text="Cancel" id="b3" immediate="true"
             actionListener="#{TheBean.cancelButtonActionListener}"/>

public void cancelButtonActionListener(ActionEvent actionEvent) {
   getPopup().cancel();
}
 

That's it!

Smart Auto-PPR Change Event Policy

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:

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!