• The closest parent directory that contains an alp.application file (even empty file) unless there is no closer parent directory that conatins an alp.site file.
• If alp.site file exist in a closer parent directory and no alp.application file is found before it - this directory is the root of the application.

In other words like in the classic ASP application cannot cross the borders of the virtual site and the virtual site is assumed to be an implicit root of the application if no explicit definition is found. The only difference is that ALP determines the site structure by inspecting the directory tree for alp.site and alp.application files.

The global.asa is executed when the application is entered for the first time and when new user session begins. In ALP the session is usually only one but depending on your settings in the alp.application file it can expire and this will invoke global.asa again if a new session is to be created. The ALP default session settings set 20 minutes expire time in order to not mislead the developers who seek ALP - classic ASP compatibility.

The global.asa file may contain the following elements:

• <OBJECT RUNAT=SERVER SCOPE=scope ...></OBJECT>
• <SCRIPT RUNAT=SERVER LANGUAGE=scriptlanguage></SCRIPT>
  • Session_OnStart routine
  • Application_OnStart routine
• <!-- #include virtual="path" -->

Note that no <% %> tags are allowed in the global.asa nor in any include files referred in it.

OBJECT tag

Creates an object and adds it to the StaticObjects collection of the Application or Sesion object. The attributes supported are:

<OBJECT
  RUNAT=SERVER
  SCOPE="scope"
  PROGID="programID"
  CLASSID="classID"
  ID="name"
></OBJECT>

RUNAT=SERVER is required. If not specified the object will be skipped and ALP will leave the element "as is" for further processing by the browser on the client side.

SCOPE can be Session or Application keywords. The keyword used determines in which StaticObjects collection the object will be placed.

PROGID or CLASSID - Only one of the both must be specified. If PROGID is used you need to specify the program ID for the object, and if CLASSID is used you must specify the ClassID - {xxxx-....} for the object (autorun applications should use ClassIDs).

ID - defines the object name under which the object will be placed in the StaticObjects collection. Further the object is made accessible to each page in the application under this name directly. I.e. you can refer to the name specified in the ID parameter as to a regular variable in the page that contains the object. This simplifies the usage of any globally used object and can be thought as for an extending the ASP object model with custom objects.

Remarks: Using this element the application is able to create some components in global.asa file and depend on them in its ASP pages. The objects life-time is the same as their scope (e.g. they live with the Application or the Session objects). However in ALP unlike classic IIS you can delete a static object from a regular ASP page (using the VarDictionary methods over the StaticObjects collection), but this is not recommended as it will render the application incompatible with IIS.

In both: classic ASP and ALP the objects created in global.asa can be apartment, both or free threaded. 

SCRIPT tag

Envelops a script executed during the global.asa processing. All the global code in such an element will be executed during any execution of global.asa file. As the global.asa execution ends the script is unloaded so you must not assign in-script objects to the Application and Session collections! This behavior matches the classic ASP behavior - one example for a common error is assigning an JScript Array object to Session or Application variable. After completing the global.asa this array will no longer be available and will cause program errors. If you need to keep large amounts of data use explicitly created VarDictionary objects or create/load data using the ConfigFile component for example. The ALP run-time library (ActiveX Pack1) contains also other objects that can be used for the purpose in more complicated situations - like mixing data kept in memory with data kept in files.

Syntax:

<SCRIPT
  RUNAT=SERVER
  LANGUAGE=language
  ID="name"
>
the script code
</SCRIPT>

RUNAT=SERVER is required. If not present the script is assumed client side and is skipped for further processing by IE.

LANGUAGE specifies the name of the script language used - like VBScript or JScript.

ID is optional and is useful only when debugging the application - it is shown when an error is displayed.

The global.asa as any ASP page may contain sections written in different script languages. Global.asa in ALP may contain two optional function/subs which will be called by the ALP engine automatically when new session or application is initialized:

Session_OnStart - Called when new session is just created.

Application_OnStart - Called when the application is first entered (first request to an URL that points into that application)

In these routines you can put your Application or Session initialization code. The most popular practice is a combination of OBJECT tags and initialization of the objects in one of the both functions (as appropriate concerning the object scope). For example you can create a DB connection object and open it in the Application_OnStart, or you can create some dictionary/collection objects and fill them in on of these two event routines.

Includes

It is quite possible you will have some include files to hold common code. Depending on the application structure they can be common for global.asa and the ASP pages as well. As the global.asa may contain only <SCRIPT RUNAT=SERVER ..> tags for the scripts the include files should not contain any <% ... %> tags!

Mapping of the paths (this concerns Server.MapPath too): 

Virtual paths are always mapped upon the site root directory.

Relative paths in global.asa are mapped upon the global.asa location. If you are interested in IIS compatibility note that this differs from the IIS behavior where they are mapped upon the file pointed by the current request (which makes the relative mapping unusable in the global.asa do we decided to do something else). 

Notes:

The objects created in global.asa are not advised for the ALP context - i.e. their OnStartPage and OnEndPage methods will not be called! This concerns only objects especially created to interact with the ALP engine (or other ASP engine) internally. Almost all the common utility COM modules are not of this type.