Friday, March 4, 2011

Task Flow Pending Changes

Task flow as a functional unit provides great flexibility and offers developers lots of ways to get a hand on its state, transaction and management. Common requirements exist like web application needs to prompt to the user asking for save/cancel pending changes before navigating to a different frame.


In ADF, pending changes can be caught at the modal layer by calling getTransaction().isDirty() in ApplicationModuleImpl. That's common for developer to come up with at the first moment. Here I present how it's easily handled by using task flow in terms of pending changes detection.


ADF task flow, as main player in the ADF controller layer, provides several context interface to manage its state and transaction. In our case today, the context interface class is ControllerContext class.


The ControllerContext class provides per-request information about the controller state for a web application. 


To get hold of the ControllerContext in your managed bean:


ControllerContext cctx = ControllerContext.getInstance();


To detect the pending changes, there is a method "isDirty()" available in ViewPortContext or TaskFlowContext just like the one in DBTransactionImpl class. The difference as well as the advantage is the method exist in the viewController layer and no need to get hold the DataBinding and subsequent Application Module of the modal layer.


cctx.getCurrentViewPort().getTaskFlowContext().isDataDirty();
or
cctx.getCurrentViewPort().isDataDirty();


ViewPortContext.isDataDirty() 
          Returns true if this view port, or any of its children view ports, has a current task flow with uncommitted ADF model data.



TaskFlowContext.isDataDirty()
          Returns true if task flow contains any uncommitted ADF model data.

4 comments:

abbas said...

nice effort.

EV SSL said...

ADF was very popular in the 1980s in large IMS DB/DC environments as a quick development tool. Most installations used it to develop simple systems that required a low level of sophistication, and had a small budget.

Hemant said...

Hi, here is a strange problem.
When a clob data field is read from tables and rendered on the page, later if the user doesn't change anything on the page, the data model layer is marked as dirty.

The problem is, if that clob field has more than 31744 characters, even you didn't change anything, it will tell you you have uncommitted data. With less than 31744 chars, it works correctly.
Any idea why so!!!

JayJay Zheng said...

Hemant,

No idea and would like to know the answer!