JDev 11.1.2.0.0 – af:showDetailItems and af:regions – the power of Facelets – part 3

The previous blog posts in this series (part 1 and part 2) looked at the behaviour of the af:region tag embedded in a af:showDetailItem tag with JDeveloper 11.1.1.4.0. This post investigates the changing nature of the "deferred" activation property for the underlying af:region task flow binding in JDev 11.1.2.0.0.

JDeveloper 11.1.2.0.0 introduces JSF 2.0 and Facelets as the predominate display technologies for ADF Faces RC pages. As Oracle's JSF 2.0 roadmap for ADF states: "The introduction of Facelets addresses the shortcomings of JSP and improves the developer page design and reuse experience."

One of these improvements is how the "deferred" activation property for task flow bindings under af:regions works, and we no longer require the programmatic solution.

The behaviour using JSPX

Before we can show how Facelets improves the use of embedded task flows in an closed af:showDetailItem tag, it's worthwhile showing that using JSPXs under 11.1.2.0.0 still has the previous behaviour where a programmatic solution is required.

If we take the same code from the previous posts written in JDev 11.1.1.4.0, specifically using a JSPX page, this time entitled BasicShowDetailItem.jspx:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core"
          xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>
  <f:view>
    <af:document title="ShowDetailJSPX" id="d1">
      <af:form id="f1">
        <af:panelAccordion id="pa1">
          <af:showDetailItem text="DummyShowDetailItem" disclosed="true" id="sdi1">
            <af:outputText value="DummyValue" id="ot1"/>
          </af:showDetailItem>
          <af:showDetailItem text="Charlie" disclosed="false" id="sdi2">
            <af:region value="#{bindings.CharlieTaskFlow1.regionModel}" id="r1"/>
            <af:commandButton text="Submit2" id="cb2"/>
          </af:showDetailItem>
        </af:panelAccordion>
      </af:form>
    </af:document>
  </f:view>
</jsp:root>

Note the embedded af:region containing a call to a task flow CharlieTaskFlow:

Also as per the previous posts, we're using the LogBegin Method Call in the task flow above, as well as task flow initializers and finalizers to helps us understand if the CharlieTaskFlow has been executed at all:

The code that does the logging again is similar as the previous posts:

public class CharlieBean {

    public static ADFLogger logger = ADFLogger.createADFLogger(CharlieBean.class);

    private String charlieValue = "charlie1";

    public void setCharlieValue(String charlieValue) {
        logger.info("setCharlieValue called(" + (charlieValue == null ? "<null>" : charlieValue) + ")");
        this.charlieValue = charlieValue;
    }

    public String getCharlieValue() {
        logger.info("getCharlieValue called(" + (charlieValue == null ? "<null>" : charlieValue) + ")");
        return charlieValue;
    }

    public void taskFlowInit() {
        logger.info("Task flow initialized");
    }

    public void taskFlowFinalizer() {
        logger.info("Task flow finalized");
    }

    public void logBegin() {
        logger.info("Task flow beginning");
    }
}

...and for the record we've inserted a custom JSF PhaseListener to assist interpreting the logger output:

public class PhaseListener implements javax.faces.event.PhaseListener {
 
  public static ADFLogger logger = ADFLogger.createADFLogger(PhaseListener.class);
  
  public void beforePhase(PhaseEvent phaseEvent) {
    logger.info(phaseEvent.getPhaseId().toString());    
  }
  
  public void afterPhase(PhaseEvent phaseEvent) {
    logger.info(phaseEvent.getPhaseId().toString());
  }

  public PhaseId getPhaseId() {
    return PhaseId.ANY_PHASE;
  }
}

And finally in this example, note the task flow binding options "activation" and "active". We'll set this back to the defaults "deferred" and null to show the behaviour of task flows under 11.1.2.0.0 using JSPXs:

On running this code under a JSPX page in 11.1.2.0.0, even though the af:showDetailItem that contains the af:region and task flow are closed, we see the following log output that shows that the task flow is still being executed:

<PhaseListener> <beforePhase> RESTORE_VIEW 1
<PhaseListener> <afterPhase> RESTORE_VIEW 1
<PhaseListener> <beforePhase> RESTORE_VIEW 1
<PhaseListener> <afterPhase> RESTORE_VIEW 1
<PhaseListener> <beforePhase> RENDER_RESPONSE 6
<CharlieBean> <taskFlowInit> Task flow initialized
<CharlieBean> <logBegin> Task flow beginning
<PhaseListener> <afterPhase> RENDER_RESPONSE 6 

The behaviour using Facelets

From here we'll show an example using Facelets. From here the example is virtually identical, except the page containing the af:region, as well as the fragment from the CharlieTaskFlow have to be created as Facelets page and fragment respectively.

As example the Facelet page code entitled FaceletsShowDetailItem.jsf looks as follows:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view xmlns:f="http://java.sun.com/jsf/core" xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <af:document title="ShowDetailItemFacelet.jsf" id="d1">
    <af:form id="f1">
      <af:panelAccordion id="pa1">
        <af:showDetailItem text="DummyShowDetailItem" disclosed="true" id="sdi1">
          <af:outputText value="DummyValue" id="ot1"/>
        </af:showDetailItem>
        <af:showDetailItem text="Charlie" disclosed="false" id="sdi2">
          <af:region value="#{bindings.CharlieTaskFlow1.regionModel}" id="r1"/>
          <af:commandButton text="Submit2" id="cb2"/>
        </af:showDetailItem>
      </af:panelAccordion>
    </af:form>
  </af:document>
</f:view>

Then compared to our previous JSPX example, every other option is exactly the same. The most significant option is the task flow binding activation and active properties, which we can see are still set to "deferred" and null:

On running the Facelet page, even though the af:showDetailItem containing the af:region isn't open, unlike our previous behaviour using JSPX where we could see the task flow unnecessary initialized, from our logs with Facelets we can see that's not happening:

<PhaseListener> <beforePhase> RESTORE_VIEW 1
<PhaseListener> <afterPhase> RESTORE_VIEW 1
<PhaseListener> <beforePhase> RESTORE_VIEW 1
<PhaseListener> <afterPhase> RESTORE_VIEW 1
<PhaseListener> <beforePhase> RENDER_RESPONSE 6
<PhaseListener> <afterPhase> RENDER_RESPONSE 6 

Once we open the af:showDetailItem, the task flow is then correctly initialized:

<PhaseListener> <beforePhase> RESTORE_VIEW 1
<PhaseListener> <afterPhase> RESTORE_VIEW 1
<PhaseListener> <beforePhase> APPLY_REQUEST_VALUES 2
<PhaseListener> <afterPhase> APPLY_REQUEST_VALUES 2
<PhaseListener> <beforePhase> PROCESS_VALIDATIONS 3
<PhaseListener> <afterPhase> PROCESS_VALIDATIONS 3
<PhaseListener> <beforePhase> UPDATE_MODEL_VALUES 4
<PhaseListener> <afterPhase> UPDATE_MODEL_VALUES 4
<PhaseListener> <beforePhase> INVOKE_APPLICATION 5
<PhaseListener> <afterPhase> INVOKE_APPLICATION 5
<PhaseListener> <beforePhase> RENDER_RESPONSE 6
<CharlieBean> <taskFlowInit> Task flow initialized
<CharlieBean> <logBegin> Task flow beginning
<CharlieBean> <getCharlieValue> getCharlieValue called(charlie1)
<CharlieBean> <getCharlieValue> getCharlieValue called(charlie1)
<PhaseListener> <afterPhase> RENDER_RESPONSE 6 

This small change saves us from having to programmatically control the refresh of the task flows, and in addition shows that Oracle is enhancing the support for ADF through Facelets rather than the traditional JSPX view display technology. This should encourage greenfield developers to pursue Facelets in context of JDev 11.1.2.0.0.

Sample Application

A sample application for 11.1.2.0.0 application is available here.

Thanks

This post was inspired by Oracle's Steve Davelaar who highlighted the new region processing in JDev 11.1.2. The introduction of the new 11.1.2 feature led me to explore the default behaviour under 11.1.1.4.0 without the new feature.