If you have have a task flow designed to use shared data control, and still don't want different instances of task flows to use same view object instances, then this post is for you.
Use case: Multiple instances of task flow should share same transaction context, however each UI should work independently when they are embedded in a parent page. As of now, there is no direct support for this. In this post I'm sharing a work around solution for this kind of scenario.
Solution: As I said earlier, this is just a work around solution, and intended to give you some idea on the implementation. Feel free to modify the code in the attached sample to meet your use cases.
Step 1. Edit the iterator used for for those pages fragments which needs to work independently, and alter binding for the view object instance used for this iterator to use an EL. EL takes the view object instance name from a PageFlow scoped variable.
Step 2. The PageFlow scoped variable that stores view object instance name used in the EL(step1 ) is populated from task flow initializer with some unique names. Task flow has a default method activity defined which will create corresponding view object instance in the Application Module before showing the page.
Download
You can download the sample workspace from here.
[Runs with Oracle JDeveloper 11.1.2.0.0 (11g R2) + HR Schema]
A glance at the implementation
Run main.jsf.
This page contains multiple instances of dept-task-flow-definition. However the page fragment used in each instances of task flow works independently using different view object instances eve though the dept-task-flow-definition has shared Data Control scope. This is done using the above idea. Take a look at TaskFlowDCHelper class to learn more about the implementation. Method TaskFlowDCHelper::initDataSource() generates the view object instance name for each instance and the same is set as initializer for dept-task-flow-definition. Method TaskFlowDCHelper::cleanupDataSource() is set as finalizer for task flow.
Use case: Multiple instances of task flow should share same transaction context, however each UI should work independently when they are embedded in a parent page. As of now, there is no direct support for this. In this post I'm sharing a work around solution for this kind of scenario.
Solution: As I said earlier, this is just a work around solution, and intended to give you some idea on the implementation. Feel free to modify the code in the attached sample to meet your use cases.
Step 1. Edit the iterator used for for those pages fragments which needs to work independently, and alter binding for the view object instance used for this iterator to use an EL. EL takes the view object instance name from a PageFlow scoped variable.
<iterator Binds="#{pageFlowScope.VOInstName}" RangeSize="25" DataControl="AppModuleDataControl" id="DepartmentsView1Iterator"/>
Step 2. The PageFlow scoped variable that stores view object instance name used in the EL(step1 ) is populated from task flow initializer with some unique names. Task flow has a default method activity defined which will create corresponding view object instance in the Application Module before showing the page.
Download
You can download the sample workspace from here.
[Runs with Oracle JDeveloper 11.1.2.0.0 (11g R2) + HR Schema]
A glance at the implementation
Run main.jsf.
This page contains multiple instances of dept-task-flow-definition. However the page fragment used in each instances of task flow works independently using different view object instances eve though the dept-task-flow-definition has shared Data Control scope. This is done using the above idea. Take a look at TaskFlowDCHelper class to learn more about the implementation. Method TaskFlowDCHelper::initDataSource() generates the view object instance name for each instance and the same is set as initializer for dept-task-flow-definition. Method TaskFlowDCHelper::cleanupDataSource() is set as finalizer for task flow.
3 comments:
Where do removeVO method execute?
or ... How can i implemnent it? (when taskflow change i.e.)
One possible place could be taskflow finalizer
certainly, a very good post
Thanks
Post a Comment