Sunday May 27, 2012

Page based Prematurely Terminating Task Flow scenario

In a previous blog post I highlighted the issue of ADF Prematurely Terminating Task Flows, essentially where ADF page fragment based task flows embedded in regions can be terminated early by their enclosing page causing some interesting side effects.  In that post I concluded the behavior was restricted to task flows embedded in regions, and to be honest besides a log out/timeout scenario, I thought this issue could only occur in regions.

While reading our documentation on the CLIENT_STATE_MAX_TOKENS and browser back button support I realized there is indeed another prematurely terminating task flow scenario for page based task flows rather than fragment based task flows which we'll describe here.  For anyone who hasn't read the previous blog post, I suggest you read it before reading this post as it won't make much sense otherwise.

Let's describe the application we'll use to demonstrate the scenario:

1) First it contains an unbounded task flow which includes a ViewCountries.jspx page to show data from the Countries table, followed by call to a countries-task-flow.xml.



2) The ViewCounteries.jspx page contains a read-only af:table showing countries data and the ability to select a record, an edit button to navigate to the countries-task-flow, and finally a plain old submit button.



4) The countries-task-flow includes an EditCountries.jspx and an exit Task Flow Return Commit activity.



Note the countries-task-flow transaction options are set to Always Begin New Transaction and a shared Data Control Scope:



6) Finally the EditCountries.jspx page includes an editable af:form for the countries data, and a button to exit the task flow via the Task Flow Return Commit activity.



Similar to the last blog post we'll use ADFLoggers on the underlying Application Module to show what's happening under the hood.

On running the application and accessing the ViewCountries.jspx page
we see the Application Module initialized in the logs:

<AppModuleImpl> <create> AppModuleImpl created as ROOT AM
<AppModuleImpl> <prepareSession> AppModuleImpl prepareSession() called as ROOT AM

We'll pick the Brazil record....



....then the edit button which navigates us to the EditCountries.jspx page within the countries-task-flow.  Note the Brazil record is showing as the current row as the countries-task-flow is using a shared data control scope:



Now if we use the browser back button to return to the previous page we see something interesting in the logs as soon as we click the button.....

<AppModuleImpl> <beforeRollback> AppModuleImpl beforeRollback() called as ROOT AM

....and because of the rollback note that the current row has reset to the first row:


As promised this is another prematurely terminating task flow scenario, this time with pages rather than fragments.  As we can see the framework on detecting the back button press terminates the task flow's transaction by automatically issuing the rollback.

You can download the sample application from here.

Thursday May 17, 2012

Which JDeveloper is right for me?

Developers downloading JDeveloper will notice that there are two "current" releases to download, 11g Release 1 and 11g Release 2 (abbreviated to 11gR1 and 11gR2 respectively).  11gR1 encompasses the 11.1.1.X.0 JDeveloper versions including the latest 11.1.1.6.0 release.  11gR2 encompasses the 11.1.2.X JDeveloper versions including the latest 11.1.2.2.0 release.

What's the difference between the two releases and when would you want to use them?

JDeveloper 11g Release 2 includes support for JavaServer Faces 2.0 and was released for customers who are specifically interested in using this contemporary Java EE technology.  Oracle plans to bring in full Java EE 6 support in JDeveloper 12c which JSF2.0 is apart of, but in listening to customers there was interest in obtaining the JSF2.0 support earlier.  Thus the 11gR2 release.

The question begs then why would you want 11gR1 if 11gR2 includes the latest Java EE JSF standards?  Surely 11gR1 only supports the older JSF1.2?  The answer revolves around JDeveloper's Fusion Middleware (FMW) support.  Only 11gR1 and the yet-to-be-released 12c versions of JDeveloper will support the full FMW tools including WebCenter, SOA Suite and so on.

So if you want the latest JSF2.0 support go 11gR2, but if you're happy with 11gR1 or need the rest of the FMW stack stay on the 11gR1 platform for now as Oracle is continuing to actively improve it.  Eventually JDeveloper 12c will arrive where the 11gR1 and 11gR2 releases will converge, and your choice will again be a simple one.

Friday May 04, 2012

ADF UI Shell update

Developers who use the ADF UI Shell (aka Dynamic Tab Shell) will be interested to know it now has support for multi browser tabs.  What does multi browser tab support mean?

As separate to the dynamic tab feature provided by the ADF UI Shell, contemporary browsers give the user the ability to open multiple tabs within the browser. Each browser tab can view different URLs allowing the user to browse different websites simultaneously, or even the same website multiple times. 

There's effectively two ways you can currently be using the ADF UI Shell, either you're using the version coupled with JDeveloper and selected through the New Page dialog the Dynamic Tab Shell template, or you've downloaded the source code via the ADF UI Shell patterns page.

If you're using the former option, note that the multi browser tab support within the Shell  became available in JDeveloper 11.1.1.6.0 (patchset 5).  If you want to make use of this support you will need to consider adding the context parameter USE_PAGEFLOW_TAB_TRACKING to your web.xml to turn on the multi browser tab support in the shell.  By default the Shell will not turn this on for backwards compatibility reasons.

Alternatively if you're using the ADF UI Shell source code as downloaded via the original pattern web page, you will not only need to configure this new parameter, but you will need to download the source code (via the zip in the link above) and modify your local copy of the template too.  For reference the only code change has been to the TabContext.java class.

Note while this will make the ADF UI Shell ready for multi browser tab support, it does not mean your entire application suddenly can support multi browser tabs. You need to have taken special care in determining your application's bean scopes as detailed in one of my old blogs.

About

Chris Muir - Oracle ADF Product Manager - The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« May 2012 »
SunMonTueWedThuFriSat
  
1
2
3
5
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
28
29
30
31
  
       
Today