Technical Articles relating to Oracle Development Tools and Frameworks

  • ADF
    March 1, 2012

uncommittedDataWarning - It's a Matter of Timing

Duncan Mills

An interesting nugget came across my desk yesterday that I though was worth sharing. What's wrong with this picture:

Task flow Diagram

Absolutely nothing right?  That's exactly the kind of taskflow we would expect to see where the user can, from the listEmployee screen, either create a new empty record by following the new navigation rule or edit the current row using the edit rule. The problem in this particular case was, however, that the employeeList screen has uncommittedDataWarning="on" set as an attribute on the document component:

<af:document title="Employee List" 

So what happens? Every time the new navigation rule is followed to navigate to the editEmployee screen the uncommitted data warning pops up.  So what's going on here? The listEmployee screen is read only in this case how could it have marked the data control as dirty? 

Well it all comes down to the timing of when the uncommittedDataWarning takes place. The check will be made when the JSF View ID is being changed.  If you look at the above taskflow you'll see that the createInsert method binding will take place before the navigation away from the page, so at the point in time that the continue navigation is invoked the DataControl will be dirty after all and the uncommittedDataWarning check will fail, popping up the dialog. 

The solution in this case is simple (assuming that you have to keep the uncommittedDataWarning="on" on the source page). You can revert to the technique that we used to use in ADF before TaskFlows came along.  You create the method binding for the createInsert operation in the employeeEdit Screen and add an invokeAction in the executables section of the pageDef which is conditional on a flag set on the request. Something like this:

<invokeAction id="InvokeCreateIfRequired" 
              RefreshCondition="#{requestScope.editAction eq 'INSERT'}"

Then the command item that triggers the navigation to the edit page sets that flag (or does not set it if you want to do an edit rather than an insert) :

<af:commandButton text="New" id="cb1" action="new"> 
  <af:setPropertyListener from="#{'INSERT'}"

So there you go - there is life in the old techniques yet! 

Join the discussion

Comments ( 1 )
  • guest Friday, March 9, 2012

    Note that 'ifNeeded' is not applicable for invokeAction

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha