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();
Returns true if this view port, or any of its children view ports, has a current task flow with uncommitted ADF model data.
Returns true if task flow contains any uncommitted ADF model data.
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.
Comments
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!!!
No idea and would like to know the answer!