When building interactive, data-driven Web applications, the ability to access and manage session state values is critical. In Oracle Application Express, session state is automatically managed for every page and easily referenced in static HTML or logic controls such as processes or validations.
Topics in this section include:
See Also:
"Referencing Item Values"You can reference item values stored in session state in regions, computations, processes, validations, and branches. An item can be a field, a text area, a password, a select list, or a check box. Table 3-3 describes the supported syntax for referencing item values.
Table 3-3 Syntax for Referencing Item Values
| Type | Syntax | Description |
|---|---|---|
|
SQL |
|
Use standard bind variable syntax for items whose names are no longer than 30 characters. Use this syntax for references within a SQL query and within PL/SQL. |
|
PL/SQL |
|
Use PL/SQL syntax to reference an item value using the See Also: Oracle Application Express API Reference |
|
PL/SQL |
|
Use standard PL/SQL syntax referencing the numeric item value using the See Also: Oracle Application Express API Reference |
|
Static text (exact) |
|
For static text or an exact substitution use the convention
|
You set the value of an item in your application and therefore session state using one of the following methods:
Form submission. See "Form Submission Example".
Bind variable. See "About Bind Variable Syntax".
Computation. See "Understanding Application Computations".
f?p syntax. See "Using f?p Syntax to Link Pages"
When a user submits a page, the Application Express engine automatically stores values typed into fields (items) in session state. For example, suppose you have an application containing two pages. The first page of the application contains a form in which a user can enter a phone number. You defined this form by creating an item named P2_PhoneNo. On the second page, you want to display the information the user enters in the form.
When the page is submitted, Oracle Application Express captures the value entered in the phone number field and stores the value for future use. The phone number entered by the user can then be retrieved from session state by referencing the item associated with the field on the page.
As you develop your applications, you may find it useful to clear the cached value for specific items, all items on a page, all pages in an application, or the current user session. Clearing a cached value resets the value to null. The topics that follow offer specific examples of clearing session state.
Topics in this section include:
Clearing cache for a single item resets the value of the item to null. For example, you might use this approach to make sure a specific item's value is null when a page is prepared for rendering.
The following example uses standard f?p syntax to clear the cache for an item. This example calls page 5 of application 100. Placing MY_ITEM in the ClearCache position of the f?p syntax resets the value of MY_ITEM to NULL.
f?p=100:5:&APP_SESSION.::NO:MY_ITEM
The following example resets the value of the items THE_EMPNO and THE_DEPTNO.
f?p=100:5:&APP_SESSION.::NO:THE_EMPNO,THE_DEPTNO
Caching application items provides an effective way to maintain session state. However, there are occasions when you may want to clear the cache for all items on a page. For example, suppose you needed to clear all fields on a page when a user clicks a link that creates a new order. By clearing the cache for an entire page, you set the value of all items on the page to null.
This example clears the session cache for two pages and resets pagination.
f?p=6000:6003:&APP_SESSION.::NO:RP,6004,6014
This example:
Runs page 6003 of application 6000 and uses the current session ID
Indicates to not show debug information (NO)
Clears all values maintained by the current session's cache for items of pages 6004 and 6014
Resets region pagination (RP) on page 6003 (the requested page)
This example shows how to implement an update form. It clears existing information and sets the item's value (typically a primary key).
f?p=6000:6003:&APP_SESSION.::NO:6003:MY_ITEM:1234
This example:
Runs page 6003 of application 6000 and uses the current session ID
Indicates to not show debug information (NO)
Clears all values maintained by the current session's cache for items on page 6003
Sets the session state of an item called MY_ITEM to the value 1234
This example is similar to the previous example, except it passes values to multiple items.
f?p=6000:6004:&APP_SESSION.::NO:6003:MY_ITEM1,MY_ITEM2,MY_ITEM3:1234,,5678
This example:
Runs page 6004 of application 6000 and uses the current session ID
Clears the current session's cache for items on page 6003
Indicates debug information should be hidden (NO)
Sets the value of MY_ITEM1 to 1234, sets the value of MY_ITEM2 to null (indicated by the comma used as placeholder), and sets the value of MY_ITEM3 to 5678
You can clear an application's cache by using f?p syntax and creating a Clear Cache argument using the keyword APP. For example:
f?p=App:Page:Session::NO:APP
Note:
Resetting the cache for an entire application does not restore the application to a completely reset state. For example, if an application includes on-new instance computations or on-new instance processes, the Application Express engine runs these computations and processes when the application session is created. Then, it processes the clear cache request and displays the requested page.To reset an application completely without a session ID (if no cookie is used to track the session ID), you must request it using a URL without a session ID, or by calling APEX_UTIL.CLEAR_APP_CACHE from another application. If the session ID is tracked using a cookie, you will need to logout to reset the state.
You can use bind variables syntax anywhere in Oracle Application Express where you are using SQL or PL/SQL to reference session state of a specified item. For example:
SELECT * FROM employees WHERE last_name like '%' || :SEARCH_STRING || '%'
In this example, the search string is a page item. If the region type is defined as SQL Query, you can reference the value using standard SQL bind variable syntax. Using bind variables ensures that parsed representations of SQL queries are reused by the database, optimizing memory usage by the server.
When using bind variable syntax, remember the following rules:
Bind variable names must correspond to an item name.
Bind variable names are not case-sensitive.
Bind variable names cannot be longer than 30 characters (that is, they must be a valid Oracle identifier).
Although page item and application item names can be up to 255 characters, if you intend to use an application item within SQL using bind variable syntax, the item name must be 30 characters or less.
If your region type is defined as a SQL Query, SQL Query (plsql function body returning SQL query), or list of values (LOV), you can reference session state using the following syntax:
:MY_ITEM
One common way to do this is to incorporate a session state variable in a WHERE clause. The following example shows how to bind the value of the item THE_DEPTNO into a region defined from a SQL Query.
SELECT last_name, job_id, salary FROM employees WHERE department_id = :THE_DEPTNO
See Also:
"Understanding Regions" for information about creating regionsFor region types defined as a PL/SQL Procedure, regions are constructed using PL/SQL anonymous block syntax. In other words, the beginning and ending keywords are used to enclose the PL/SQL block. For example:
IF :P1_JOB IS NOT NULL THEN INSERT INTO employees (employee_id, first_name, job_id) VALUES (:P1_EMP_ID, :P1_NAME, :P1_JOB) end if;
In this example, the values of the employee_id, first_name, and job_id are populated by the values of P1_EMP_ID, P1_NAME, and P1_JOB.