Master-child BTF chaperone – a contextual event alternative
Inter Bounded Task Flows (BTF) communications are aided in JDeveloper 11g by the use of contextual events, a BTF publish-subscribe mechanism for passing data between BTFs. Yet in some situations contextual events may be the equivalent of "using a sledge hammer to crack a nut", where developers try and use them everywhere when there are alternative techniques available that may work just as well.
This blog documents a technique for allowing a master ADF application utilising the ADF UI Shell to provide services to a child BTF, including passing data backwards and forwards, without the use of contextual events. While the blog demonstrates a solution within context of the ADF UI Shell, the overall technique should be useful in other ADF solutions.
It needs to be clearly highlighted at the beginning of this post this is just a single technique that has use in certain circumstances, it's not a replacement for all the different ways contextual events can be used. The reader should take care to read the full blog post then conduct a post analysis where this technique would be useful.
Preamble
Readers working with the ADF UI Shell will hopefully be familiar with Pino Jeddah's excellent work in documenting different methods of integrating BTFs into the shell. Recently Pino was inspired by a post I wrote to the OTN forums ADF UI Patterns and Best Practices. In this post I described a problem I was having with the ADF UI Shell, namely how to combine the ADF UI Shell's "dirty tab" functionality with a self-closing standalone BTF. Pino devised an excellent solution and blogged about it showing a very interesting technique with contextual events. I recommend all readers interested in contextual events and inter BTF communications check it out.
While pondering the problem I stumbled across a new technique demonstrated in this blog. The technique is inspired by my work with the ADF UI Shell, but should be general enough that it can be used in other ADF domains.
Problem Description
One of the guiding features of ADF via JDeveloper 11g that influences application design is task flows. Typically a master ADF application is made up of one Unbounded Task Flow (UTF) calling multiple Bounded Task Flows (BTF). Ideally to maximise reuse, the BTFs should be built in such a fashion that they are totally agnostic of how and who consumes them. This ideal would allow BTFs to be reused by different master ADF applications, essentially a set of reusable loosely coupled services (along the lines of Avrom Roy-Faderman's ideas of SOA in ADF for extreme reusability).
Yet dependent on the design challenge at hand, there are times when the child BTF needs to communicate with its caller. Maybe there's the need to pass data backwards and forwards, or possibly there's services that the child BTF requires that only the calling application can provide.
To make this example real, consider the following.
Imagine a master ADF application based on the ADF UI Shell that allows users to search for departments, and then in a new separate tab either view details about the selected department or separately view a list of employees. Essentially each BTF spawns another leaving the previous open, and within the ADF UI Shell the user manages the opening and closing of the BTFs through the UI Shell tabs feature.
Decomposing these requirements into an ADF solution, our end solution will be:
a) A master ADF application to call the Search Departments BTF
b) A Search BTF that opens either the Departments BTF, or the Employees BTF
c) A View Departments BTF accepting a department ID, showing the specific department's details
d) A View Employees BTF also accepting the department ID, showing the employees relating to the department
To maximize reusability the Search BTF, Departments BTF and Employees BTF will all be built as standalone ADF Libraries, consumed by the master ADF application through JDeveloper's Resource Palette. This allows the resulting BTFs to be used by other master ADF applications beyond the current master.
Yet our goal of reusability is partially compromised as the Search BTF is hardcoded into calling the Departments BTF or the Employees BTF, they are effectively tightly coupled, the enemy of reusability. Who is to say in the future that a new master ADF application may want to make use of our sophisticated Search BTF, but display entirely different BTFs when the user selects a record? To maximize reusability, depending on the master ADF application consuming the Search BTF, we need some sort of mechanism to allow the master ADF application to plug in functionality into the Search BTF such that alternative BTFs can be opened, yet the specific BTFs aren't hardcoded into the Search BTF.
Assumptions
For purposes of keeping this blog entry short, we'll only consider the artifacts to be created in the master ADF application and the Search BTF. We won't consider how to create the master ADF application based on the ADF UI Shell, nor how to create the Search BTF itself – it is expected readers are familiar with these concepts and how to build them.
As a complete exercise the technique detailed here could be extended to the Department BTF and Employees BTF. Yet detailing the solution for the master ADF application and the Search BTF application is enough to describe the technique and then readers need just extend it to the other BTFs. A sample application is available at the end of this post that pulls them altogether.
Solution – Search BTF
For the Search BTF the solution requires the following artifacts:
* A fragment displaying the departments, including two commandButtons to open either the Department or Employees BTF:
Name: pSearchBTFImpl
Class: searchbtf.view.SearchBTFInterface
Value: #{pageFlowScope.pSearchBTFImpl}
* A request bean to capture the fragment commandButton events:
* Modify the original commanButtons to call the bean's method:
Solution – Master ADF Application
For the Master ADF Application the solution requires the following artifacts:
* The ADF Library for the Search BTF (adflibSearchBTF.jar) to be added to the Master ADF Application's ViewController project.
* An implementation of the ADF UI Shell Launcher class to open new tabs in the shell (see the following zip file from Oracle to see an example of the Launcher class)
* A concrete implementation of searchbtf.view.SearchBTFInterface that is not available to the Master ADF Application:
The complete result is at runtime the master ADF application's Chaperone class with the concrete implementation on how to call the other BTFs is passed to the Search BTF. The Search BTF is aware of the available methods as it defined the interface class that the master Chaperone class was based on. The end effect is the Search BTF defines a set of required services it wants the calling application to supply and implement.
That concludes the work required for the master ADF application.
Sample Application
The sample application using Oracle's HR sample schema can be downloaded as a zip, containing all 4 applications, the master ADF application, Search BTF, Employees BTF and Department BTF. Note that the 3 BTFs deploy their ADF Libraries into a lib directory of the master ADF application, which in turn attaches the JARs to it's ViewController project.
Conclusion
The master-child BTF chaperone approach is an alternative technique to contextual events where the child BTF requires services from its caller, but isn't interested in the implementation. This allows a relatively lighter coupling that assists BTF reusability. The technique isn't a replacement for contextual events in all cases, but should highlight to developers an alternative mechanism for achieving communications between BTFs.
Addendum
Tested under JDev 11.1.1.2.0 build 5536.
This blog documents a technique for allowing a master ADF application utilising the ADF UI Shell to provide services to a child BTF, including passing data backwards and forwards, without the use of contextual events. While the blog demonstrates a solution within context of the ADF UI Shell, the overall technique should be useful in other ADF solutions.
It needs to be clearly highlighted at the beginning of this post this is just a single technique that has use in certain circumstances, it's not a replacement for all the different ways contextual events can be used. The reader should take care to read the full blog post then conduct a post analysis where this technique would be useful.
Preamble
Readers working with the ADF UI Shell will hopefully be familiar with Pino Jeddah's excellent work in documenting different methods of integrating BTFs into the shell. Recently Pino was inspired by a post I wrote to the OTN forums ADF UI Patterns and Best Practices. In this post I described a problem I was having with the ADF UI Shell, namely how to combine the ADF UI Shell's "dirty tab" functionality with a self-closing standalone BTF. Pino devised an excellent solution and blogged about it showing a very interesting technique with contextual events. I recommend all readers interested in contextual events and inter BTF communications check it out.
While pondering the problem I stumbled across a new technique demonstrated in this blog. The technique is inspired by my work with the ADF UI Shell, but should be general enough that it can be used in other ADF domains.
Problem Description
One of the guiding features of ADF via JDeveloper 11g that influences application design is task flows. Typically a master ADF application is made up of one Unbounded Task Flow (UTF) calling multiple Bounded Task Flows (BTF). Ideally to maximise reuse, the BTFs should be built in such a fashion that they are totally agnostic of how and who consumes them. This ideal would allow BTFs to be reused by different master ADF applications, essentially a set of reusable loosely coupled services (along the lines of Avrom Roy-Faderman's ideas of SOA in ADF for extreme reusability).
Yet dependent on the design challenge at hand, there are times when the child BTF needs to communicate with its caller. Maybe there's the need to pass data backwards and forwards, or possibly there's services that the child BTF requires that only the calling application can provide.
To make this example real, consider the following.
Imagine a master ADF application based on the ADF UI Shell that allows users to search for departments, and then in a new separate tab either view details about the selected department or separately view a list of employees. Essentially each BTF spawns another leaving the previous open, and within the ADF UI Shell the user manages the opening and closing of the BTFs through the UI Shell tabs feature.
Decomposing these requirements into an ADF solution, our end solution will be:
a) A master ADF application to call the Search Departments BTF
b) A Search BTF that opens either the Departments BTF, or the Employees BTF
c) A View Departments BTF accepting a department ID, showing the specific department's details
d) A View Employees BTF also accepting the department ID, showing the employees relating to the department
To maximize reusability the Search BTF, Departments BTF and Employees BTF will all be built as standalone ADF Libraries, consumed by the master ADF application through JDeveloper's Resource Palette. This allows the resulting BTFs to be used by other master ADF applications beyond the current master.
Yet our goal of reusability is partially compromised as the Search BTF is hardcoded into calling the Departments BTF or the Employees BTF, they are effectively tightly coupled, the enemy of reusability. Who is to say in the future that a new master ADF application may want to make use of our sophisticated Search BTF, but display entirely different BTFs when the user selects a record? To maximize reusability, depending on the master ADF application consuming the Search BTF, we need some sort of mechanism to allow the master ADF application to plug in functionality into the Search BTF such that alternative BTFs can be opened, yet the specific BTFs aren't hardcoded into the Search BTF.
Assumptions
For purposes of keeping this blog entry short, we'll only consider the artifacts to be created in the master ADF application and the Search BTF. We won't consider how to create the master ADF application based on the ADF UI Shell, nor how to create the Search BTF itself – it is expected readers are familiar with these concepts and how to build them.
As a complete exercise the technique detailed here could be extended to the Department BTF and Employees BTF. Yet detailing the solution for the master ADF application and the Search BTF application is enough to describe the technique and then readers need just extend it to the other BTFs. A sample application is available at the end of this post that pulls them altogether.
Solution – Search BTF
For the Search BTF the solution requires the following artifacts:
* A fragment displaying the departments, including two commandButtons to open either the Department or Employees BTF:
* An interface class containing two stubbed methods for opening the Department BTF and the Employees BTF respectively:
emptyText="#{bindings.DepartmentsView1.viewable ? 'No data to display.' : 'Access Denied.'}"
fetchSize="#{bindings.DepartmentsView1.rangeSize}" rowBandingInterval="0"
selectedRowKeys="#{bindings.DepartmentsView1.collectionModel.selectedRow}"
selectionListener="#{bindings.DepartmentsView1.collectionModel.makeCurrent}" rowSelection="single" id="t1"
columnStretching="column:c2">
headerText="#{bindings.DepartmentsView1.hints.DepartmentId.label}" id="c2">
headerText="#{bindings.DepartmentsView1.hints.DepartmentName.label}" id="c1">
* A task flow parameter based on the interface:
package searchbtf.view;
public interface SearchBTFInterface {
public void openDepartment(oracle.jbo.domain.Number departmentId);
public void openEmployees(oracle.jbo.domain.Number departmentId);
}
Name: pSearchBTFImpl
Class: searchbtf.view.SearchBTFInterface
Value: #{pageFlowScope.pSearchBTFImpl}
* A request bean to capture the fragment commandButton events:
Note how the openDepartment and openEmployees functions within this bean don't open the Department or Employees BTF directly. They instead grab the SearchBTFInterface as passed in as a parameter on the BTF from the calling application, and calls the defined methods of the interface class.
package searchbtf.view;
import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;
import javax.faces.application.Application;
import javax.faces.context.FacesContext;
import javax.faces.event.ActionEvent;
import oracle.adf.model.BindingContext;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCIteratorBinding;
import oracle.jbo.Row;
public class ViewDepartments {
public ViewDepartments() { }
// Resolve EL expression - sourced from JsfUtils from Oracle Corp
public static Object resolveExpression(String expression) {
FacesContext facesContext = FacesContext.getCurrentInstance();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExp = elFactory.createValueExpression(elContext, expression, Object.class);
return valueExp.getValue(elContext);
}
public SearchBTFInterface getSearchBTFInterface() {
SearchBTFInterface searchBTFInterface = (SearchBTFInterface)resolveExpression("#{pageFlowScope.pSearchBTFImpl}");
return searchBTFInterface;
}
public oracle.jbo.domain.Number getDepartmentId() {
DCBindingContainer bc = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
DCIteratorBinding iterator = bc.findIteratorBinding("DepartmentsView1Iterator");
Row currentRow = iterator.getCurrentRow();
oracle.jbo.domain.Number departmentId = (oracle.jbo.domain.Number)currentRow.getAttribute("DepartmentId");
return departmentId;
}
public void openDepartment(ActionEvent actionEvent) {
oracle.jbo.domain.Number departmentId = getDepartmentId();
if (departmentId != null)
getSearchBTFInterface().openDepartment(departmentId);
}
public void openEmployees(ActionEvent actionEvent) {
oracle.jbo.domain.Number departmentId = getDepartmentId();
if (departmentId != null)
getSearchBTFInterface().openEmployees(departmentId);
}
}
* Modify the original commanButtons to call the bean's method:
That concludes the work within the Search BTF. What readers should understand is the Search BTF through the combination of the Java interface and the BTF parameter, is enforcing that the calling BTF supplies a concrete implementation of the interface. In other words the Search BTF is avoiding the real implementation of how to call the other Department and Employees BTF. It's leaving the actual implementation to the caller (which will be the master BTF application in our case).
Solution – Master ADF Application
For the Master ADF Application the solution requires the following artifacts:
* The ADF Library for the Search BTF (adflibSearchBTF.jar) to be added to the Master ADF Application's ViewController project.
* An implementation of the ADF UI Shell Launcher class to open new tabs in the shell (see the following zip file from Oracle to see an example of the Launcher class)
For those familiar with the ADF UI Shell Launcher class and the launchActivity method, note the subtle difference in this implementation. Essentially a local variable keeps a reference to the UI TabContext class, and used in the launchActivity methods. This is required because when the Search BTF indirectly calls the launchActivity methods via the concrete implementation of the interface passed from the master application, TabContext is outside the child BTF's scope. In turn the Launcher bean must remain in the master ADF application sessionScope such that the TabContext isn't flushed on each request.
package masterapp.view;
import java.util.HashMap;
import java.util.Map;
import javax.faces.event.ActionEvent;
import oracle.ui.pattern.dynamicShell.TabContext;
public class Launcher {
private TabContext tabContext;
public Launcher() {
this.tabContext = (TabContext)JsfUtils.resolveExpression("#{viewScope.tabContext}");
}
public void openSearch(ActionEvent ae) {
openSearch();
}
public void openSearch() {
Map parameterMap = new HashMap();
parameterMap.put("pSearchBTFImpl", new SearchBTFChaperone());
launchActivity("Search", "/WEB-INF/SearchBTF.xml#SearchBTF", true, parameterMap);
}
public void openDepartments(oracle.jbo.domain.Number departmentId) {
Map parameterMap = new HashMap();
parameterMap.put("pDepartmentId", departmentId);
launchActivity(this.tabContext, "Department", "/WEB-INF/DepartmentBTF.xml#DepartmentBTF", true, parameterMap);
}
public void openEmployees(oracle.jbo.domain.Number departmentId) {
Map parameterMap = new HashMap();
parameterMap.put("pDepartmentId", departmentId);
launchActivity(this.tabContext, "Employees", "/WEB-INF/EmployeesBTF.xml#EmployeesBTF", true, parameterMap);
}
protected void launchActivity(TabContext tabContext, String title, String taskflowId, boolean newTab) {
try {
if (newTab) {
tabContext.addTab(title, taskflowId);
} else {
tabContext.addOrSelectTab(title, taskflowId);
}
} catch (TabContext.TabOverflowException toe) {
toe.handleDefault();
}
}
protected void launchActivity(TabContext tabContext, String title, String taskflowId, boolean newTab, Map parameters) {
try {
if (newTab) {
tabContext.addTab(title, taskflowId, parameters);
} else {
tabContext.addOrSelectTab(title, taskflowId, parameters);
}
} catch (TabContext.TabOverflowException toe) {
toe.handleDefault();
}
}
protected void launchActivity(String title, String taskflowId, boolean newTab) {
launchActivity(this.tabContext, title, taskflowId, newTab);
}
protected void launchActivity(String title, String taskflowId, boolean newTab, Map parameters) {
launchActivity(this.tabContext, title, taskflowId, newTab, parameters);
}
}
* A concrete implementation of searchbtf.view.SearchBTFInterface that is not available to the Master ADF Application:
As can be seen the Chaperone class simply grabs the Launcher class and calls the associated methods for opening the BTFs.
package masterapp.view;
import oracle.jbo.domain.Number;
import searchbtf.view.SearchBTFInterface;
public class SearchBTFChaperone implements SearchBTFInterface {
public SearchBTFChaperone() { }
public Launcher getLauncher() {
Launcher launcher = (Launcher)JsfUtils.resolveExpression("#{launcher}");
return launcher;
}
public void openDepartment(Number departmentId) {
getLauncher().openDepartments(departmentId);
}
public void openEmployees(Number departmentId) {
getLauncher().openEmployees(departmentId);
}
}
The complete result is at runtime the master ADF application's Chaperone class with the concrete implementation on how to call the other BTFs is passed to the Search BTF. The Search BTF is aware of the available methods as it defined the interface class that the master Chaperone class was based on. The end effect is the Search BTF defines a set of required services it wants the calling application to supply and implement.
That concludes the work required for the master ADF application.
Sample Application
The sample application using Oracle's HR sample schema can be downloaded as a zip, containing all 4 applications, the master ADF application, Search BTF, Employees BTF and Department BTF. Note that the 3 BTFs deploy their ADF Libraries into a lib directory of the master ADF application, which in turn attaches the JARs to it's ViewController project.
Conclusion
The master-child BTF chaperone approach is an alternative technique to contextual events where the child BTF requires services from its caller, but isn't interested in the implementation. This allows a relatively lighter coupling that assists BTF reusability. The technique isn't a replacement for contextual events in all cases, but should highlight to developers an alternative mechanism for achieving communications between BTFs.
Addendum
Tested under JDev 11.1.1.2.0 build 5536.
RSS
Email