UI Shell - closing dirty activities when switching globalTabs

Question

We're currently using the UI Shell with several globalTabs. In one of the tabs via the Launcher we open an activity when the user clicks on the relevant link via the following code:
public void openCreateSubmission(ActionEvent actionEvent) {
prxForm.setUsesUpload(true);
_launchActivity("Create Submission", "/WEB-INF/flows/create-submission.xml#create-submission", false);
currentTabDirty(actionEvent);
Note how we implicitly mark the activity as dirty as opening our activity/btf is the start of a transaction.
With the globalTabs and other navigable items on the screen, rather than disabling them while the activity is dirty in the current globalTab, we'd rather allow the user to select an alternative globalTab and then warn them that the current tab is dirty, displaying the appropriate dialog that's build into the UI Shell.
To do this I've added the following code:
<af:commandNavigationItem text="Welcome" id="cni1" action="Welcome"
actionListener="#{backingBeanScope.shellLauncher.closeCurrentActivity}"/>
Problem I'm hitting is the dirty dialog is displaying after the tab navigation has occurred, not before, which defeats the point.
I'm a bit surprised by this behaviour as the actionListener code should fire before the action property navigation.
Suggestions?
Cheers
CM.

Answer 1

Thanks for the feedback Richard.
Regards "It is a best practice recommendation from Oracle to use managed beans to store logic that is related to the UI rendering only. All application data and processing should be handled by logic in the business layer of the application." ... yeah, yeah, yeah ;-) However in this case we have a 3rd party library we're calling that is doing work on our behalf, the data control feature we could use for publishing it through the binding layer for non BC components has always being wonky and badly documented, so it's just easier to call it from the JSF managed bean. But point taken.
Regards "unified method" ... ok, accepted limitation.
With regards the uncommittedDataWarning, I note that it is a warning mechanism and not an error mechanism (or at least, it doesn't have an option to enforce no navigation). It would seem ideal, especially with it's backbutton functionality, to display an error only, leaving the user on the same page, and forcing them to do a commit. Obviously this wouldn't be ideal in all cases, but certainly in some. Do you agree? I'll raise an ER if so.
Cheers,
CM.