The task flow mechanism embodies one of the key value propositions of the
ADF Framework, it's primary contribution being the componentization of your applications and implicitly the introduction of a re-use culture, particularly in large applications.
However, what if we could do more? How could we make task flows even more re-usable than they are today? Well one great technique is
to take advantage of a feature that is already present in the framework, a feature which I will call, for want of a better name, "adaptive bindings".
What's an adaptive binding? well consider a simple use case. I have several screens within my application which display tabular data which are all essentially identical, the only difference is that they happen
to be based on different data collections (View Objects, Bean collections, whatever) , and have a different set of columns. Apart from that, however, they happen
to be identical; same toolbar, same key functions and so on. So wouldn't it be nice if I could have a single parametrized task flow
to represent that type of UI and reuse it?
Hold on you say, great idea, however,
to do that we'd run into problems. Each different collection that I want
to display needs different entries in the pageDef file and:
I want
to continue
to use the
ADF Bindings mechanism rather than dropping back
to passing the whole collection into the taskflow
If I do use bindings, there is no way I want
to have
to declare iterators and tree bindings for every possible collection that I might want the flow
to handle
Ah, joy! I reply, no need
to panic, you can just use adaptive bindings.
Defining an Adaptive Binding
It's easiest
to explain with a simple before and after use case. Here's a basic pageDef definition for our familiar Departments table.
<executables>
<iterator Binds="DepartmentsView1"
DataControl="HRAppModuleDataControl"
RangeSize="25"
id="DepartmentsView1Iterator"/>
</executables>
<bindings>
<tree IterBinding="DepartmentsView1Iterator" id="DepartmentsView1">
<nodeDefinition DefName="
oracle.demo.model.vo.DepartmentsView" Name="DepartmentsView10">
<AttrNames>
<Item Value="DepartmentId"/>
<Item Value="DepartmentName"/>
<Item Value="ManagerId"/>
<Item Value="LocationId"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>
Here's the adaptive version:
<executables>
<iterator Binds="${pageFlowScope.voName}"
DataControl="HRAppModuleDataControl"
RangeSize="25"
id="TableSourceIterator"/>
</executables>
<bindings>
<tree IterBinding="TableSourceIterator" id="GenericView">
<nodeDefinition Name="GenericViewNode"/>
</tree>
</bindings>
You'll notice three changes here.
Most importantly, you'll see that the hard-coded View Object name that formally populated the iterator Binds attribute is gone and has been replaced by an expression (${pageFlowScope.voName}). This of course, is key, you can see that we can pass a parameter
to the task flow, telling it exactly what VO to instantiate to populate this table!
I've changed the IDs of the iterator and the tree binding, simply
to reflect that they are now re-usable
The tree binding itself has simplified and the node definition is now empty. Now what this effectively means is that the #{node} map exposed through the tree binding will expose every attribute of the underlying iterator's collection - neat! (kudos
to Eugene Fedorenko at this point who reminded me that this was even possible in his excellent "deep dive" session at OpenWorld this year)
Using the adaptive binding in the UI
Now we have a parametrized binding we have
to make changes in the UI as well, first of all
to reflect the new ID that we've assigned
to the binding (of course) but also
to change the column list from being a fixed known list
to being a generic metadata driven set:
<af:table value="#{bindings.GenericView.collectionModel}"
rows="#{bindings.GenericView.rangeSize}"
fetchSize="#{bindings.GenericView.rangeSize}"
emptyText="#{bindings.GenericView.viewable ? 'No data
to display.' : 'Access Denied.'}"
var="row" rowBandingInterval="0"
selectedRowKeys="#{bindings.GenericView.collectionModel.selectedRow}"
selectionListener="#{bindings.GenericView.collectionModel.makeCurrent}"
rowSelection="single" id="t1">
<af:forEach items="#{bindings.GenericView.attributeDefs}" var="def">
<af:column headerText="#{bindings.GenericView.labels[def.name]}" sortable="true"
sortProperty="#{def.name}" id="c1">
<af:outputText value="#{row[def.name]}" id="ot1"/>
</af:column>
</af:forEach>
</af:table>
Of course you are not constrained
to a simple read only table here. It's a normal tree binding and iterator that you are using behind the scenes so you can do all the usual things, but you can see the value of using ADFBC as the back end model as you have the rich pantheon of UI hints
to use
to derive things like labels (and validators and converters...)
One Final Twist
To finish on a high note I wanted
to point out that you can take this even further and achieve the ultra-reusability I promised. Here's the new version of the pageDef iterator, see if you can notice the subtle change?
<iterator Binds="{pageFlowScope.voName}"
DataControl="${pageFlowScope.dataControlName}"
RangeSize="25"
id="TableSourceIterator"/>
Yes, as well as parametrizing the collection (VO) name, we can also parametrize the name of the data control. So your task flow can graduate from being re-usable within an application to being truly generic. So if you have some really common patterns within your app you can wrap them up and reuse then across multiple developments without having
to dictate data control names, or connection names. This also demonstrates the importance of interacting with data only via the binding layer APIs. If you keep any code in the task flow generic in that way you can deal with data from multiple types of data controls, not just one flavour. Enjoy!
