Zheng Tech Blog

This is an example topic followed by the previous post. Here I am presenting an example that using a popup to confront the user to save or forget the pending changes when navigate to different frame. The example can be download from here . The example is based on Andrejus Baranovskis's example on how to detect pending changes using dynamic region s. What Andrejus did for pending changes is to throw an Warning message, but I came up with a scenario that to confront the user with popup and let use to choose either stay on the page or go ahead forget the change for the next frame. 1. How the pending changes are detected through ADF controller layer. 2. How to navigate to a different frame in dynamic region. If there are pending changes, the popup will be thrown to the user. 3. How to handle the logics if the user choose to forget the pending changes and navigate away. 4. Main.jspx page structure: Here are the UI of this example: 1. Make s

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: ControllerCo

Task flow is a great feature in ADF and serve as a milestone for ADF 11g. The best documentation for ADF matters is to dig into the fusion developer's guide. The particular matter for task flow is here  (11.1.1.3). In ADF task flow, there is a concept - "transaction". It is a persisted collection of work that can be committed or rolled back as a group. Task flow present itself as a perfect group for such transaction. Transaction applies when one task flow is interacting with another. For example, there are two task flows here, one is parent task flow (flow P) and the other is child task flow (flow C). When P calls C, there are several transaction options for C. The options specify whether C will join P's existing transaction, create its own transaction or only create its own transaction if no existing transaction in P. Of course, C could also not have a transaction at all, which is the default option. Steve Muench stated the following in his article : If your bo