Managing State in an HTML-Client Application

User interaction with a BI Beans thin bean can incrementally change the state of the bean. For example, drilling in a thin crosstab changes the state of the data query that the crosstab displays. Each thin bean keeps track of its state changes. Your application will also have state information, such as the name of the current page, the thin presentation that the page displays, and so on.

The state of each thin bean is important for supporting bookmarks and the use of the Back functionality of a browser. For example, if a user bookmarks a page that includes a crosstab, and that crosstab displays an altered data query, then your servlet needs to reproduce the crosstab and the altered data query. If a user drills in a crosstab and then chooses the Back button in the browser, then your servlet must display the crosstab as it existed before the drill operation.

Where to store thin-bean state

Thin beans keep track of their state changes, and they have a getState method for retrieving a string of these state changes. You must be able to retrieve the state string later, to recreate the page. You can:

Because queries, especially, can have very large state strings, it is better to store query state strings in a State object. Because presentation state is meaningless without the query state, it is also good practice to store presentation state strings in a State object.

You normally store the Catalog location of a thin presentation in the URL, with other application state information, and you can store state strings for view tools and explorer beans in the URL. If you have long strings that describe application state, and you are concerned about the size of the URL, then you can add application state strings to the State object that contains the thin-bean state.

State management for the Back button

To allow users to return to a previous page within a session, as with the Back button, for example, your servlet needs to be able to redisplay a thin presentation in a previous state. The thin presentation and the query should already be stored in the HTTP session, so you do not have to reinstantiate them. You do need to display the appropriate presentation, and to set the state of the thin presentation bean, and of its query, to match the page that the user wants to return to.

To support returning to a page within a session, you can store State objects in the HTTP session, as you do the thin presentation beans and their queries. You can use an oracle.cabo.servlet.state.StateManager to get and store State objects.

State management for bookmarks

To allow users to bookmark a page, your servlet needs to be able to reproduce the page outside of the current session. You must be able to locate the thin presentation bean in the BI Beans Catalog and to load it. You must also set the state as it was in the bookmarked page. For bookmarks, you cannot store State objects in the session.

You could store state strings directly in the URL, but the length of the query state can cause the URL to exceed its bounds, and your application would fail. Instead, to support the bookmarking of a page, store the state string in a State object, and save the State object to the BI Beans Catalog, through the oracle.dss.thin.state.BIStateManager. The BIStateManager implements the oracle.cabo.servlet.state.StateManager interface, but it has added methods for saving State objects to the Catalog. You can use checkpointing to store some of the state information in State objects in the BI Beans Catalog and other state information in the URL or in State objects in the session.

You might decide that bookmarking does not need to be supported in all pages in your application. If, for example, you allow users to save edited presentations to the BI Beans Catalog, you might not need to support bookmarks for each change that users make as they edit.

BI Beans Request-Handling Sequence
Getting Thin-Bean State
Setting Thin-Bean State
Checkpointing Thin-Bean State