By Frank Nimphius-Oracle on Jan 28, 2015
MAF 2.1 has been released to public and the New features document mentions a feature provides a behavior to task flows that is familiar for ADF developers:
"Support for limiting pageFlowScope variables to task flow boundariesMAF 2.1.0 provides the ability to restrict the scope of a pageFlowScope variable to the bounded task flow only. Any updates to the variable in one bounded task flow would not impact a pageFlowScope variable with the same name in another bounded task flow. To force this behaviour, the following flag must be set:
Without this flag, the default behavior matching previous MAF releases will be enforced, such that changes made to the variable in the second bounded task flow would impact the variable in the first bounded task flow."
What the new feature document doesn't tell you is where this flag needs to be set. Here is where our MAF documentation comes into play (Our doc writers really do an amazing job in keeping up with the changes in this so quickly evolving product. Plus the way they explain the product is - at least in my opinion - outstanding work):
"18.104.22.168 What You May Need to Know About Behavior of New Bounded Task Flows
The value of the
page-flow-scope-behavior element is set to
push-new by default and is displayed in the Overview and Source editors for the new task flow, as well as the Properties window for the
So the good news is that this is the default behavior now. Another good news is that the product doesn't enforce this setting on applications that are upgraded from MAF 2.0.1 or even ADF Mobile. However, after analyzing your applications, you should switch to this setting if you can make sure that this doesn't negatively impact your application.
The reason why you want to move to using the new default setting (push-new) is isolation of your managed beans or variables you save in pageFlowScope. MAF does not support reuse on the task flow level. But even without, if you treat task flows as units of work and an ability to split the work within development teams, you can see how a conflicting name of a memory variable could cause funny side effects if an old value set in the parent task flow is shown. In addition task flows could be the only feature in a FAR file, which then would be similar to reusing task flows on a task flow level. If you make assumption about the existence of a shared pageFlowScope variable, where could this get you to?
So architecture wise, ensure page flow scopes of bounded task flows are isolated and use task flow input parameters to share data between a called and a calling task flow. This puts you onto the safe side of life and the new MAF default setting supports you with this.