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!
