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!
