uncommittedDataWarning - It's a Matter of Timing

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" 
             uncommittedDataWarning="on"> 

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" 
              Binds="CreateInsert" 
              RefreshCondition="#{requestScope.editAction eq 'INSERT'}"
              Refresh="ifNeeded"/> 

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'}" 
                           to="#{requestScope.editAction}" 
                           type="action"/>
</af:commandButton>

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

Comments:

Note that 'ifNeeded' is not applicable for invokeAction

Posted by guest on March 09, 2012 at 07:53 AM GMT #

Post a Comment:
Comments are closed for this entry.
About

Hawaii, Yes! Duncan has been around Oracle technology way too long but occasionally has interesting things to say. He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse
Follow DuncanMills on Twitter

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.
However, don't be put off, I want to hear what you have to say!

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today