As you respond to requests in a servlet that includes the BI Beans thin beans,
you get the state of each thin bean and store it so you can recreate the page
later if a user returns to the page. You get the state after all thin-bean events
have been handled. To get the state of a thin bean, you call its getState
method. You can store the returned state string in the URL or in a UIX State
object.
You can store the state of the explorer thin beans and of tools in the URL without having to worry about URL overflow. You should be very careful, however, about storing the state of queries and the presentations that display them. Query state can grow large enough to cause the URL to exceed its boundaries.
Through HTTP query parameters, you use hidden form fields to add state information
to the URL. You add the hidden form fields to the UINode
for the
page thatyou will display in the HTTP response.
In servlet applications, when you use HTTP POST requests, you can also encode
the parameters in the Destination
of a form, rather than in hidden
form fields. Note that you cannot use POST requests in a JSP application.
The following example shows one way to store state information in a URL. This
example assumes that you have an Explorer Detail defined as myExplorerDetail
.
// this code comes after any thin-bean events have been handled // create a form for the UINode FormBean form = new FormBean("MyForm"); // add page contents here -- code not included in this example // add the state of the Explorer Detail to the form form.addIndexedChild(new FormValueBean(myExplorerDetail.getThinBeanName(), myExplorerDetail.getState()); // you can also add application parameters to the URL here // form.addIndexedChild(new FormValueBean("appParam1", "appParamValue1")); // then, render the HTML page // code not included in this example
You should store the state of queries and of thin presentation beans in a State
object. State
objects are part of the UIX state-management support
in the oracle.cabo.servlet.state
package. You use the StateManager
interface, the State
interface, and the MutableState
interface, which extends State
.
In a servlet application, you use the UIX state management support to store
state information in the HTTP session. If you use UIX Controller, then you store
the state in a BajaContext
, as described in the UIX Controller
chapter in the UIX Programmer's Guide.
Whether you use UIX Controller or some other page management mechanism, if
you store State
objects in the HTTP session, then you can use the
oracle.cabo.servlet.state.QueueStateManager
as the StateManager
.
If you need to use checkpointing, then use an oracle.dss.thin.state.BIStateManager
as the StateManager
. The BIStateManager
supports saving
State
objects to the BI Beans Catalog.
The UIX QueueStateManager
and the BIStateManager
both implement the StateManager
interface. They manage 20 State
objects by default. This allows users to return to 20 different pages in a single
session. You can increase this number if you like. For each request, you get
the State
from the StateManager
and set it on the
appropriate objects. After you handle the request, you store a new MutableState
object in the StateManager
.
The following code shows how to retrieve the QueueStateManager
from the HTTP session or how to create the QueueStateManager
and
store it in the session. This code increases the size of the queue to manage
25 State
objects.
// get the StateManager from the HTTP session // httpSession is the HttpSession from the request or new one StateManager stateManager= (StateManager)httpSession.getAttribute("state_manager"); if (stateManager == null){ stateManager = new QueueStateManager(25); httpSession.setAttribute("state_manager", stateManager); }
If you intend to save State
objects in the BI Beans Catalog, as
you do when you use checkpointing, use the BIStateManager
instead
of the QueueStateManager
. The BIStateManager
requires
a BIContext
that represents the Catalog folder where State
objects are stored. In this example, the BIContext
is named context
.
// get the StateManager from the HTTP session // httpSession is the HttpSession from the request or new one StateManager stateManager= (StateManager)httpSession.getAttribute("state_manager"); if (stateManager == null){ stateManager = new BIStateManager(context, 25); httpSession.setAttribute("state_manager", stateManager); }
After you handle any thin-bean events that are in the URL, you need to store
the new state with the StateManager
. You place the state ID in
the URL. The following code shows how to store state information for the thin
crosstab and the Query. This example uses the ThinBeanName
as the
key in the MutableState
.
// this code comes after any thin-bean events have been handled // get a new State object from the StateManager MutableState newState = stateManager.getNewState();
// place crosstab state in the State newState.putValue(myCrosstab.getThinBeanName(), myCrosstab.getState()); // place query state in the State newState.putValue(myQuery.getThinBeanName(), myQuery.getState()); // you can also add application state info // newstate.putValue("appParam1", "appParamValue1"); // get the ID from the State String stateID = newstate.getID(); // put the state in a form FormBean form = new FormBean("MyForm"); // add page contents here // code not included in this example // then add hidden form fields form.addIndexedChild(new FormValueBean("stID", stateID)); // then, render // code not included in this example
If you use the ServletRequestHandler
,then you can add the state
information to the MutableState
as shown in the following code.
// requestHandler is the ServletRequestHandler // OK for encoder to be null requestHandler.getState(provider.getURLEncoder()); // get state ID, place in hidden form field, as in previous example
Managing State in an HTML-Client
Application
Setting Thin-Bean State
BI Beans Request-Handling
Sequence
Checkpointing Thin-Bean
State
Rendering Thin Beans