One of the most common mistakes that I see when reviewing ADF application code, is the sin of storing UI component references, most commonly things like table or tree components in Session or PageFlow scope. The reasons why this is bad are simple; firstly, these UI object references are not serializable so would not survive a session migration between servers and secondly there is no guarantee that the framework will re-use the same component tree from request
to request, although in practice it generally does do so.
So there danger here is, that at best you
end up with an NPE after you session has migrated, and at worse, you
end up pinning old generations of the component tree happily eating up your precious memory. So that's clear, we should never. ever, be storing references
to components anywhere other than request scope (or maybe backing bean scope). So double check the scope of those binding attributes that map component references into a managed bean in your applications.
Why is it Such a Common Mistake?
At this point I want
to examine why there is this urge
to hold onto these references anyway? After all, JSF will obligingly populate your backing beans with the fresh and correct reference when needed.
In most cases, it seems that the rational is down
to a lack of distinction within the application between what is data and what is presentation. I think perhaps, a cause of this is the logical separation between business data behind the ADF data binding (#{bindings}) façade and the UI components themselves. Developers tend
to think, OK this is my data layer behind the bindings object and everything else is just UI. Of course that's not the case. The UI layer itself will have state which is intrinsically linked
to the UI presentation rather than the business model, but at the same time should not be tighly bound
to a specific instance of any single UI component. So here's the problem. I think developers try and use the UI components as state-holders for this kind of data, rather than using them
to represent that state. An example of this might be something like the selection state of a tabset (panelTabbed), you might be interested in knowing what the currently disclosed tab is. The temptation that leads
to the component reference sin is
to go and ask the tabset what the selection is. That of course is fine in context - e.g. a handler within the same request scoped bean that's got the binding
to the tabset. However, it leads
to problems when you subsequently want the same information outside of the immediate scope. The simple solution seems
to be
to chuck that component reference into session scope and then you can simply re-check in the same way, leading of course
to this mistake.
Turn it on its Head
So the correct solution
to this is
to turn the problem on its head. If you are going
to be interested in the value or state of some component outside of the immediate request context then it becomes persistent state (persistent in the sense that it extends beyond the lifespan of a single request). So you need
to externalize that state outside of the component and have the component reference and manipulate that state as needed rather than owning it. This is what I call the UIManager pattern.
Defining the Pattern
The UIManager pattern really is very simple. The premise is that every application should define a session scoped managed bean, appropriately named UIManger, which is specifically responsible for holding this persistent UI component related state. The actual makeup of the UIManger class varies depending on a needs of the application and the amount of state that needs
to be stored. Generally I'll start off with a Map in which individual flags can be created as required, although you could opt for a more formal set of typed member variables with getters and setters, or indeed a mix. This UIManager class is defined as a session scoped managed bean (#{uiManager}) in the faces-config.xml.
The pattern is
to then inject this instance of the class into any other managed bean (usually request scope) that needs it using a managed property. So typically you'll have something like this:
<managed-bean>
<managed-bean-name>uiManager</managed-bean-name>
<managed-bean-class>oracle.demo.view.state.UIManager</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
When is then injected into any backing bean that needs it:
<managed-bean>
<managed-bean-name>mainPageBB</managed-bean-name>
<managed-bean-class>oracle.demo.view.MainBacking</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>uiManager</property-name>
<property-class>oracle.demo.view.state.UIManager</property-class>
<value>#{uiManager}</value>
</managed-property>
</managed-bean>
In this case the backing bean in question needs a member variable
to hold and reference the UIManager:
private UIManager _uiManager;
Which should be exposed via a getter and setter pair with names that match the managed property name (e.g. setUiManager(UIManager _uiManager), getUiManager()).
This will then give your code within the backing bean full access
to the UI state.
UI components in the page can, of course, directly reference the uiManager bean in their properties, for example, going back
to the tab-set example you might have something like this:
<af:paneltabbed>
<af:showDetailItem text="First"
disclosed="#{uiManager.settings['MAIN_TABSET_STATE'].['FIRST']}">
...
</af:showDetailItem>
<af:showDetailItem text="Second"
disclosed="#{uiManager.settings['MAIN_TABSET_STATE'].['SECOND']}">
...
</af:showDetailItem>
...
</af:panelTabbed>
Where in this case the settings member within the UI Manger is a Map which contains a Map of Booleans for each tab under the MAIN_TABSET_STATE key. (Just an example you could choose
to store just an identifier for the selected tab or whatever, how you choose
to store the state within UI Manger is up
to you.)
Get into the Habit
So we can see that the UIManager pattern is not great strain
to implement for an application and can even be retrofitted
to an existing application with ease. The point is, however, that you should always take this approach rather than committing the sin of persistent component references which will bite you in the future or shotgun scattered UI flags on the session which are hard
to maintain. If you take the approach of always accessing all UI state via the uiManager, or perhaps a pageScope focused variant of it, you'll find your applications much easier
to understand and maintain. Do it today!
