Application processing in Panther occurs by executing a series of events. Panther supports several event hooks that are specific to Web applications. This chapter describes the following event types:
Web Event Hooks
Panther has four Web application event hooks where you can attach JPL procedures. Four events are defined:
web_shutdown. When one of these events occurs,
Panther searches for a JPL procedure that has the corresponding event name.
web_startupprocedure to create global variables, to establish database connections for two-tier applications, or to establish request broker connections for three-tier applications.
proc web_startup //2-tier
DBMS ENGINE jdb
DBMS DECLARE jdb_conn1 CONNECTION FOR DATABASE "videobiz"
proc web_startup //3-tier
When a screen is submitted, values are written to Panther variables which can be used in
web_enter processing. These variables tell why the screen was submitted, the object ID of the widget involved, and the occurrence number, if applicable. For more information, refer to "Web Entry Context Flags."
web_enter procedure from the Panther Gallery specifies a different graphic and hyperlink if the documents are displayed using frames.
// If using frames, use jlogomin.gif.
gallery->active_pixmap = "jlogomin.gif"
gallery->default_link = ""
// If frames unavailable, use Gallicon.gif and set hyperlink.
gallery->active_pixmap = "Gallicon.gif"
gallery->default_link = "main"
Panther generates the HTML for presentation in the browser. Screen exit processing occurs after the HTML is generated; therefore, screen exit processing cannot affect the generated HTML.
web_exit procedure unhides the grid containing the address information if the JPL global variable
show_details is set to
PV_YES. This variable is created during screen entry and is set to
proc screen_entry (data, flags)
if !(flags & K_WEBPOST)
// If this is a GET, create variable
// and set to No
global show_details = PV_NO
else // If this is a POST, create variable and set to Yes
global show_details = PV_YES
proc web_exit ()
if show_details = PV_YES // If show_details set to Yes for
// a POST, grid is unhidden
address_grid->hidden = PV_NO
else // hide grid
address_grid->hidden = PV_YES
web_startup. You can also use it to perform any other necessary clean up.
Note that this procedure is only called if the application shuts down cleanly, such as with the monitor utility.
proc web_shutdown //2-tier
DBMS ENGINE jdb
DBMS CLOSE CONNECTION jdb_conn1
proc web_shutdown //3-tier
When a Web application event occurs, Panther searches for a JPL procedure with the event name and, if found, executes it.
Panther executes the first JPL procedure that it finds with this name, using this search algorithm:
Panther uses the procedure in the most recently loaded module.
SMINITJPL. Because Panther automatically publics this module as part of its initialization, the default processing for each of the Web event hooks can be defined here.
Given this search order, a Web application can have multiple JPL procedures for the same event. For example, you can define the
web_enter procedure and issue the public command on it at application startup; this procedure performs default processing for all screens. However, a specific screen can have its own
web_enter procedure; when this screen is open, Panther finds its
web_enter procedure first and executes it. The default
web_enter procedure is executed when subsequent screens open that lack their own
Web Application Events
After Panther is installed and configured on your system, each Web application server performs the following steps when it is initialized:
SMINITJPLin smvars.bin or in the Web application's [initialization file.
If the Web application server receives a request to terminate from the monitor utility, it performs the following steps:
For each screen request or submission, Panther performs these steps:
POST, restores the contents of fields as specified by data from the browser and from the server cache.
GET, processes variable assignments from the
Controlling Entry Processing
K_WEBPOST is a context bit flag that is set to true when Panther opens a screen because of a browser's
POST command. When you press a push button on a browser screen, the data is sent back to the HTTP server with the
POST method and the
K_WEBPOST flag is set. If part of that screen's processing is to open another screen on the Panther server,
K_WEBPOST flag is not set for the second screen. Only after you post the second screen back to the server does the
K_WEBPOST flag get set.
For example, your application screen selects data from the database on screen entry and displays that data to the user so that the user can make a selection. At this point, Panther performs these actions:
The user then makes a selection and submits the screen back to the server where Panther performs these actions:
You can test the
K_WEBPOST flag so that the screen entry procedure selects data only when a user requests the screen, not when the user submits the screen back to the server on a
POST. For example:
proc scr_entry(scr_name, flags)
if !(flags & K_WEBPOST)
DBMS QUERY SELECT title_id, name, pricecat FROM titles
In the Panther Gallery, HTTP Request Method illustrates a screen using
K_WEBPOST. The Panther Gallery is accessible from the Web application server:
An option menu widget can have its Drop Down Source property set to External Screen so that it gets its data from a database. When a Panther screen has an option menu thus set, its screen entry event is processed twice—when the screen initially opens, and again after it returns from populating the option menu. When the Panther screen opens on a
GET and then reopens on a
POST, the additional screen entry event that is triggered by the option menu occurs on both the
You can control screen entry processing so that it occurs only on the desired event:
OFF_EXPHIDEso that screen entry events only occur when the screen is explicitly opened.
The following JPL procedure tests the When a screen is submitted, values are written to the following variables for use in
K_WEBPOST so that screen entry processing occurs only on
POST events; this processing is avoided when screen entry occurs after option menu initialization:
proc scr_entry (name, flags)
if ( !(flags & K_WEBPOST) && !(flags & K_EXPOSE) )
// Processing occurs only on a GET event.
if ( (flags & K_WEBPOST) && !(flags & K_EXPOSE) )
// Processing occurs only on a POST event.
Web Entry Context Flags
The following JPL procedure tests the
When a screen is submitted, values are written to the following variables for use in
Push button was pressed.
PV_BUTTON_PRESS, this will contain the object ID of the button that was pressed.
For the grid push buttons, this will contain the object ID of the grid being operated on.
Otherwise, this will contain
PV_BUTTON_PRESS, this will contain the occurrence number of the button pressed.
PV_DELETE, this will contain the occurrence being operated upon.
PV_SCROLL_BOTTOM, this will contain the occurrence number placed in the first onscreen element of the grid being scrolled.