Proxy ViewObject and Dynamic Editable UI in ADF

ADF Bindings and Data Control maps together ADF BC and ADF UI. Mapping by default is static, means ADF UI renders data collection from specific VO mapped during design time. Sometime we have requirement to change data collection rendered on ADF UI during runtime. Dynamic UI can be implemented with dynamic VO's in combination with ADF Faces Dynamic Tags (Shay Shmeltzer's blog - ADF Faces Dynamic Tags - For a Form that Changes Dynamically). Dynamic VO's are created from SQL statements during runtime - such VO's will be readonly and hard to maintain. Moreover, its very hard to customize ADF Faces Dynamic Tags layout for custom UI requirements. We can set iterator binding in Page Definition dynamically, but this works only for Master-Detail VO instances - Dynamic Iterator Binding to Reuse View Link Relationship for Master-Detail. I will present in this blog post different technique how to implement dynamic editable ADF UI, assuming number of rendered attributes is not changing - but changing data collection.

Our task - to split ADF BC and ADF UI, allow to switch during runtime from one VO to another:

Sample application - DynamicVoApp.zip, implements such use case where we switch between different VO's retrieving data from different tables (we assume VO attribute names are the same, even underlying DB table column names are different). This is common scenario for business transactional systems, such systems tend to have large number of small tables with same columns and you need to minimize number of ADF UI to render such tables based on user role, etc. Of course we could build 100 different ADF UI screens for each of 100 tables - but we can be little smarter and build only 1 ADF UI screen to render all 100 different tables. Let's see how.

First we need to define dummy proxy VO, with select * from dual - we will use this proxy VO to access real VO through Data Control from ADF UI. DataView dummy VO will act as proxy VO:

Dummy VO - DataView defines all attributes to be accessible from ADF UI and to be defined in Page Definition file (Id and Name):

Real VO - DepartmentsView, must have exactly same names for attributes as we have defined in DataView. This is important, otherwise ADF Binding will fail to retrieve attributes from Page Definition on runtime - DepartmensView (Id attribute maps with Id, Name attribute maps with Name):

Same for JobsView, only difference - Name attribute maps with Title:

AM Data Model includes only DataView, only proxy dummy VO is accessible from ADF UI in our case:

There is custom method exposed in AM, this method will be invoked as Task Flow initializer and prepare real VO to be used through proxy DataView VO:

Here is main logic for sample application - changeVOInstance(voName) method:

This method logic:

1. Get proxy DataView VO
2. Remove proxy DataView VO definition
3. Find real VO definition by path name using ViewDefImpl.findDefObject(voName) function
4. Substitute proxy DataView VO with real VO definition, by creating real VO instance under proxy VO name using createViewObject("DataView",  voDefImpl)

Method is invoked as initializer method from Task Flow:

Task Flow accepts VO path name parameter, it is passed as parameter to custom method:

Task Flow parameter is passed through PageFlow scope and Task Flow is set to be refreshed when parameter value changes (ifNeeded):

ADF UI is based on typical ADF UI component, no dynamic components - means highly customizable:

ADF UI bindings are pointing to Page Definition, where mapping with proxy DataView is defined:

On runtime, by default we render editable JobsView (Id and Title labels) - Jobs data:

Click Open Departments button - proxy DataView will be switched and DepartmentsView will be rendered instead (Id and Name labels) - Departments data:

This approach allows to edit and update rendered data:

As you can see, just with one ADF screen we have implemented two use cases - Jobs and Departments editable UI's.