General principles

A Web browser stores the history of Web pages visited for each open tab. Managing this history enables the URLs of the visited pages to be stored in the form of a stack: the user can move around the stack using the Previous and Next buttons.

The Previous button goes back one page in the stack from the current page. This feature is not enabled if the current page is the first page visited.

The Next button goes forward one page in the stack from the current page. This feature is not enabled if the current page is the last page visited.

Henceforth, an action may be defined as:

• the call of an Adelia Web program by the user when he enters the associated URL in the browser address bar,
• the triggering of an Adelia event by the user (clicking on a button object for example),
• or the triggering of an Adelia event by the program (cyclical Ajax event or pseudo-event).

In Adelia Web, each action adds a new entry to the browser history (the action processing results page). This entry is always added to the top of the stack. The browser history can be seen as a log of processed Adeila actions: each URL called defines an action in a unique way.

The Previous and Next buttons must be seen as Cancel and Redo buttons, used to browse the processed actions log. Clicking the Previous button cancels the action which produced the current page. The browser displays the previous page, which becomes the current page.

Similarly, clicking the Next button re-executes the action which produced the page after the current page. The browser displays the next page, which becomes the current page.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented by clicking on a BTN_1 button object (called "Increment").

As the log is managed as a linear stack, it is possible that certain logged actions will become unattainable when an action is triggered on a revisited page.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented by clicking on a BTN_1 button object (called "Increment").

Action A2 is deleted from the log and becomes unattainable.

Activating browser Previous/Next button support

This feature's support is defined at environment attributes level.

It can be customized for each program during program definition.

By default, this feature is disabled for all the existing environments. When a program is generated without this feature, it is not possible to browse the browser history and the Previous button has no effect: the current page (i.e. the page being processed) remains the same (the Next button remains disabled as the current page is still the last page visited).

Supported browsers

This feature is supported by the following browsers:

• • Firefox version 3.6 and above,

  • Chrome version 17 and above,

  • Internet Explorer version 8 and above.

In Internet Explorer 8 and more recent versions, all the program pages must be interpreted with a render level equal to "IE=8" or higher ("IE=9" or "IE=edge").

To put in place this configuration, refer to the Defining Page Attributes section of the online help for the "Set page attributes" button in the "Adelia Web Studio" menu bar in Dreamweaver.

In Internet Explorer 7 (and in Internet Explorer 8 or 9 if the pages are interpreted with a render level IE7), this function is disabled: it is not possible to browse the browser history and the Previous button has no effect (all the Adelia events are seen as irreversible).

The mechanisms to put in place to use the browser Previous/Next button support are described below.

↑ Top of page

Reversible/irreversible/dummy Adelia event

As an action can be associated with an Adelia event, it is possible to define rules for browsing the processed actions log according to the type of event.

These rules must be specified when defining an Adelia event for a graphical object of a page in the Dreamweaver layout manager.

Reversible event

A reversible event may be an Ajax or conventional (non-Ajax) event.

This type of event is associated with an action for which the process can be cancelled. Clicking the Previous button cancels this action and returns to the page which preceded this action.

The Next button is enabled to allow the user to redo the canceled action.

This mode is the default mode for all of a program's Adelia events when Previous / Next button support is enabled.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented during the ONCLICK reversible event processing on a BTN_1 button object (called "Increment").

Irreversible event

An irreversible event may be an Ajax or conventional (non-Ajax) event.

This type of event is associated with an action for which the process cannot be cancelled. Clicking the Previous button has no effect and the current page remains the page being processed.

The Next button remains disabled as the current page is still the last page visited.

The actions logged before executing an action associated with an irreversible event become unattainable.

This mode is the default mode for all of a program's Adelia events when Previous / Next button support is disabled.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented during the ONCLICK irreversible event processing on a BTN_1 button object (called "Increment").

Action A2 is deleted from the log and becomes unattainable after adding A2.

Dummy event

A dummy event must be an Ajax event.

This type of event is associated with an action that is not in the processed actions log. The results page for the associated process is not attainable by using the Previous and Next buttons.

This type of event may be useful in the case of a cyclical-type Adelia event in Ajax mode.

Important: The 4GL block associated with a dummy event must not contain the PROCESS, PROCESS_PGM and PROCESS_URL instructions: a dummy event must always be used to stay on the same page.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented during the ONCLICK dummy event processing on a BTN_1 button object (called "Increment").

The current page becomes the page before the results page of the latest non-dummy event (so the Google page).

Example: A PGM_A program which displays a counter initialized at 1 which can be incremented during the processing of a dummy ONCLICK event on a BTN_1 button object (called "Increment") and which can be reset during the processing of an irreversible ONCLICK event on a BTN_2 button object (called "RESET").

The current page becomes the A2 results page and not the Google page as it is the result of an irreversible event.

↑ Top of page

Saving a program

Action logging requires managing associated process logging which is based on an Adelia Web program state backup mechanism.

This backup saves the result of each process linked to an action. After each Adelia event is triggered, the program state resulting from the execution of code L4G of the corresponding "Event Management", "Init Pgm" and "Return" paragraphs is saved.

There is, therefore, an associated backup for each logged action.

Program state

The backup mechanism is used to save the state of each program being executed. The state of an Adelia Web program is made up of:

• • all the Adelia variables in the Program scope (declared in the "PGM DECL" paragraph),
  • all the Adelia data of each Web page defined in the program, i.e.
    
    
    • all the Adelia variables in the Page scope (declared in each "INITIALIZATION" paragraph),
    • all the data making up the state of each Adelia graphical object defined in a page.

Backup restore is triggered when an action cancellation request is made.

- clicking the Previous button restores the backup linked to the program state before executing the action which led to the current page,

Example: A PGM_A program which displays a counter initialized to 1 in an OUT_1 output field. This counter can be incremented during the processing of a reversible ONCLICK event on a BTN_1 button object (called "Increment") and can be reset during the processing of a reversible ONCLICK event on a CBX_1 check box object (initially unchecked and called "Reset").

(*1) Restores save associated with action A2 following the A3 cancellation request.

(*2) Re-executes the process associated with the previously-canceled action A3.

Notes:

• • the program state before executing an action associated with an irreversible event is never restored as this action cannot be canceled.
  • the program state after executing an action associated with a dummy event is never saved as this action is not in the processed actions log.

For performance and ramp-up reasons, each program state save is stored in the Web application server file system. A set of parameters allow the backup mechanism to be configured (see Log setup paragraph).

Save for a given program can be managed in two ways:

Manual save and SAVE paragraph

Manual save makes it possible to optimize the save process by selecting the relevant data making up the program state.

Optimization may, for example, consist in:

- not saving temporary variables which are only used in one stage of a calculation,

- only saving data from the current Web page if the program handles several pages.

This mode is enabled by creating a SAVE paragraph via the PAGE block context-sensitive menu.

This mode must be enabled for all the Web pages contained in a program (all the PAGE blocks must have a BACKUP sub-block).

This block's L4G code is executed after processing each reversible or irreversible Adelia event linked to the page.

If the developer wishes to refine the backup according to each processed event, he can use the reserved words *OBJ_ORIGIN and *EVT_ORIGIN. These reserved words indicate the name of the object having triggered the event and the name of the event that has just been executed respectively.

The developer must use the SAVE_PGM_STATE instruction to save data used by the program.

To disable manual save mode and enable automatic save, all the program's SAVE paragraphs must be deleted.

↑ Top of page

Cancelling and rebuilding an action

A program state is restored automatically by the system during an action cancellation request using the Previous button (independently of the automatic or manual backup mode).

However, when the processing of certain actions updates data outside the program scope (such as data stored in a database for example), it is possible to cancel these processes so that the data remains in a consistent state.

CANCEL paragraph

The CANCEL paragraph is optional and created via the PAGE block context-sensitive menu.

When the browser's Previous button is clicked, this block's L4G code is executed after restoring the program state backup triggered before the execution of the action leading to the current page. When the CANCEL paragraph is executed, the program is in the state it was in before the action to cancel was executed.

The developer must use the reserved words *OBJ_ORIGIN and *EVT_ORIGIN to distinguish the action to cancel. These reserved words indicate the name of the object having triggered the event and the name of the event to cancel respectively.

The developer must use the GET_FORM_VALUE instruction to retrieve the values of the graphical objects input by the user before processing the action to cancel.

Remember that it is not necessary in this block to process the process cancellation linked to an irreversible or dummy event.

Example: A PGM_A program which contains two input fields ENT_NAME and ENT_FIRSTNAME initialized with the "enter name" and "enter first name" values respectively and a BTN_ADD (called Add) which is used to add the name and first name input to a DB table in the reversible ONCLICK event.

(*1) Restores save associated with action A1 following the A2 cancellation request.

Clicking the Previous button:

• restores the save associated with action A1.
• triggers the CANCEL block.

To cancel the addition to the DB, the developer must know the surname and first name values that the user entered before triggering the event on the BTN_ADD button. To do this, the CANCEL block must contain the following process:

* Test if the event to cancel is the event associated with BTN_ADD

if *OBJ_ORIGIN = 'BTN_ADD'

   * The ENT_NAME and ENT_FIRSTNAME values must be retrieved when the event is triggered

   * The value properties of ENT_NAME and ENT_FIRSTNAME cannot be used directly as they are "enter name" and "enter first name" respectively

   * The GET_FORM_VALUE instruction must be used

   GET_FORM_VALUE ENT_NAME WNAME

   GET_FORM_VALUE ENT_FIRSTNAME WFIRSTNAME

   * WNAME et WFIRSTNAME have the values "dupond" and "michel"

   * The addition to DB is canceled

   DELETE_SQL USERS *COND(COL_NAME= :NAME et COL_FIRSTNAME= :FIRSTNAME)  

end

Rebuilding an action

Clicking the browser's Next button redoes the event that was previously cancelled: the 4GL block associated with this event is re-executed.

The data supplied at the start of the processing (i. e. the values of the graphical objects in the associated form) is identical to the data supplied during the previous execution of this event.

The reserved word *NEXT_ACTION allows to distinguish if a process is executed by the user normally or if this execution is triggered by clicking the browser's Next button.

(*2) Re-executes the process associated with action A2 following the A2 rebuild request. The data supplied at the star of the processing is the data supplied during the previous execution of A2.

↑ Top of page

Managing the processed actions log

A log manager is associated with each user Web session (or pseudo-session).

By default, the size of the processed actions log (i.e. the size of the stack) is infinite.

It is, however, possible to set a finite size through setup (see Log setup paragraph): in this case the manager manages a logged actions interval. When the log has reached its maximum size, each new entry inserted deletes the first interval entry: this becomes unattainable using the Previous button.

Example: A PGM_A program displaying a counter initialized to 1 which can be incremented by clicking on a BTN_1 button object (called "Increment"). We assume that the log has a maximum size of three entries and is initially empty.

(*1) As the maximum log size is reached when adding A3, A4 deletes A1 from the log and it becomes unattainable.

(*2) The user remains on the results page of A2 as A1 is unattainable.

Log purge

The system automatically manages the purge of the log and the associated backup files in the following cases:

• • an irreversible Adelia event is triggered: in this case, all previously logged actions are deleted from the log (as unattainable) and the associated backups are deleted from the file system,
  • an Adelia event is triggered from a revisited page: in this case, all the actions logged after the one having led to the current page are deleted from the log (as unattainable) and the associated backups are deleted from the file system,
  • when the log has a finite size and has reached its maximum size, if the user is on the last page of the log and if an Adelia event is triggered, the first entry in the log is deleted (as unattainable) and the related backup is deleted from the file system,
  • the HTTP session becomes invalid: the log is emptied, all the previously logged actions are deleted from the log and the associated backups are deleted from the file system.

Log setup

It is possible to configure processed action logging using the parameters in the CfgConfiguration.properties file.

These parameters:

↑ Top of page