Web Development


Chapter 7 . JPL Globals in Web Applications

Web applications can set JPL global variables to store data at three levels: application, individual users, and requests.

A sample screen in the Panther Gallery entitled JPL Globals demonstrates an application using different types of global variables; it is accessible from the Web application server:

http://server-name/cgi-bin/jwsamp/main

Application Globals

An application global is shared by all users of a jserver. To create an application global, issue the JPL global command before the web_startup event completes. You can declare application globals in the following areas:

Because changes in an application global are visible to all users, it is unusual to change an application global's value after web_startup. Instead, application globals are best used to supply values that remain constant for the duration of the application. For example, PV_YES and PV_NO are application globals whose values should remain unchanged.


Context Globals

A context global variable is private to a single user of a jserver. Its value is preserved between transmissions of the browser and HTTP server. A context global is created by creating a JPL global variable with the global command, and then calling sm_web_save_global on that variable. For example:

proc make_jpl_global
global my_global
call sm_web_save_global("my_global")
return

Panther automatically maintains a context global and its value in the application's cache file. Because each set of context globals is specific to a given user, you can use them to save user-specific information such as ID, preferences, or start time.

A context global is maintained until sm_web_unsave_global is called for that global, or all context globals are removed by sm_web_unsave_all_globals.

If the global command executes a second time, it overwrites the global's previous value. If you execute the global command in the unnamed JPL procedure or during screen entry, also test whether the screen is being opened for a GET event, because the screen is then reopened on a POST event. You can test this by using the K_WEBPOST flag or the CGI variable @cgi_request_method.

For example, the following screen entry procedure creates a JPL global variable for the current user on a GET event:

proc enter( screen, status )

if !(status & K_WEBPOST)
{
//Create a JPL global
global current_user(31)
//Make current_user a context global so it
//saved between transmissions

call sm_web_save_global( "current_user" )
}

Subsequent requests can refer to the current_user global. For example, if a later request saves changes to previously selected values, the save screen can use the user name in its status message:

proc save_changes

call sm_tm_command( "SAVE" )
if (sm_tm_inquire(TM_STATUS)==0)
{
message="Thank You, "##current_user\
##" Your changes have been saved."
}
else
{
message="Sorry, "##current_user\
##" Your changes could not be saved."
}
msg emsg message
return

Transient Global Variables

A transient global variable is one that is created after the web_startup event is complete and is not added to the cache with sm_web_save_global. A transient global exists for a single request and is destroyed during exit processing after HTML generation. A transient global is useful when a POST event opens multiple screens that need to share a data value among themselves but not with later requests.