Application object

ALP	Application object

Application object is accessible for the scripts executed by the ASP module (Internally called ScriptGen content generator). It is accessible to the ASP pages and the RAW scripts within the bounds of the same ALP Application (see also ALP URL, ALP Settings shell extensions, alp.application configuration file). It holds values and objects that the scripts can save for application wide usage across the request boundaries. ALP Engine manages Application and other global objects itself thus the ASP Module theoretically can share them with future modules for ALP providing means to integrate different technologies more tightly.

The contents of the Application collections (Contents and StaticObjects) is often referred also as Application variables.

Collections:

Contents - Contains a collection of values and objects that can be set and read by the scripts in that application.

StaticObjects - Contains a collection of the objects created using the <OBJECT RUNAT=SERVER ...> tag in global.asa

Properties:

Value - default indexed property - writes/reads to/from the Contents collection, reads also the StaticObjects collection.

Methods:

Lock - Locks the application to preserve it form changing from another scripts

UnLock - UnLocks the application and allows other scripts to make changes.

ALP 1.1 and later supports global.asa files which allow the application initialize some objects for application-wide usage thus extend the ASP object model.

Application scope is defined by the existence and settings in the alp.application configuration files and cannot cross the Virtual ALP site boundaries. Because of the desktop nature of the ALP there is a similarity between Application and Session objects but developers should use them according to their meaning in order to build applications that will work in both single user and multi user environments. For example using the Session for purposes more suitable for the Application object may require you to do certain porting work if you want to run the same application on IIS, while the correct usage will most often allow you run the application on IIS without code changes.

Locking/Unlocking is important not only because of the compatibility requirements. One browser process can open multiply windows and they can process requests simultaneously thus failing to lock the Application may cause unexpected results when you perform certain operations that must be done by a single page only. This is important for example when you set a variable accessed by many pages. To avoid locking the entire application for actions concerning only certain part of the application you can create a CustomLock object, save it an Application variable and use its Lock/Unlock methods when you synchronize the access to the sensitive resource for that part of the application.

The Application collections is implemented using the VarDictionary object thus it allows some extended manipulations by the script. Be careful when using them in order to preserve compatibility with the server side ASP provided by the IIS. It is recommended scripts targeting ASP-ALP cross-compatibility to set/read collection items only through the Value property that defines behavior compatible with the Microsoft ASP.

See usage samples in the Value property's page.

See also the ALP configuration for an overview of the ALP concepts.