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!
