• Overview (below on this page)
• Writting ASP pages
• Configuration
• Objects reference
• Raw scripts
• Compatibility with IIS

Overview

Foreword

ScriptGen module provides ALP with ability to execute Active Scripts. It uses updated version of the newObjects ScriptManager2 component from the ALP run-time library (always shipped with ALP). This generator supports two different script types - ASP-like and raw scripts. Both types share common object model and it is possible to combine the both kinds in one application. However the main purpose of this module are the ASP pages and the raw scripts are supported just as additional convenience for developers (mostly useful for test purposes).  

ASP-like scripts provide almost full compatibility with Microsoft Internet Information Server and Active Server Pages supported by it. ASP-Like scripts and the object model together implement the most used part of the functionality that can be found in the ASP on the IIS (see the compatibility notes below). 

In short about the internal architecture

Short explanation of the request processing:

Content generator holder (CGHolder) invokes the ScriptGen component and passes to it the request in the standard CCGA form. ScriptGen component used is created by the CGHolder over the configuration specified in the alp.application file (local combined with the global). Thus in the moment of initialization ScriptGen knows what kind of work it must do and what script type will be executed.

As a second step comes the negotiation between CGHolder and ScriptGen about the global/custom objects. ScriptGen supports Application and Session objects. Thus CGHolder determines if the current request belongs to a particular application and session and if the current request is the first one for the Application and Session it asks ScriptGen to create empty objects and saves them for the next requests. ScriptGen on its side obtains from the CGHolder these objects and processes the request - creates and initializes the environment objects such as Request, Server, Response.

After these objects become ready. ScriptGen initializes the ScriptHost and attaches them to the host.

ScriptGen uses passes request to determine how to load the script and activates the appropriate components if needed. At the end it has a prepared script that is loaded into the ScriptHost and executed.

During the execution script communicates with the ScriptGen using the environment objects and the output and other output information (such as headers) is passed back to the CGHolder. CGHolder buffers the output and after the end of the execution transfers the buffers to the client - usually Internet Explorer.

Notes and compatibility with the IIS ASP

Compatibility depends on the Pluggable Protocol API provided by Microsoft. ALP must act as a server and as a client at the same time and additionally it must synchronize its client functions with the Internet Explorer browser - i.e. ALP targets tight integration with the browser. Unfortunately there are several features realized in the OS as specific exceptions for the HTTP(S) only. Thus it is impossible to use the API provided features for the realization of that part of the functionality. Fortunately most of the problems caused by it are avoidable and are avoided in ALP. Another problem is that some of the required features are not available on all the platforms targeted by ALP (i.e. Windows 95). We are gradually extending ALP to cover or simulate the features that are problematic on client computers.

Here is the list of the features status/availability:

• Query string - supported. CCGA assumes always name=value format of the parameters in the query string (widely used format today). In ASP this is de-facto standard.
• Post - Form posts are supported for the url encoded form fields (format used by all browsers). Multipart forms (mostly used for file uploads) are supported as well. File uploads may look a bit strange in ALP environment, but in many cases (not only because of compatibility considerations) they allow convenient user interface to be built. For example putting/transferring  images in data bases or binary files, processing data specified by the user not relying on the file system etc.
• Environment/Server variables - supported. ALP engine itself emulates acceptable replacements for the values not available on the desktop - such as the host name for example. Replacements are designed to be useful and not to cause confusion for the scripts. Port 80 is always assumed and shown to the scripts in order to prevent them from placing :port after the host name when they are creating URL manually.
• URL - (See above notes too). ALP URL syntax is designed to "cheat" the scripts that it is a normal URL with the typical parts such as server, path, file, parameters and in the same time the URL corresponds to a local path. That behavior helps to build URL without knowing that the script runs on the desktop and gives ability to use meaningful (for the local system) URLs that can be easily converted to a local path or file: protocol URL.(see ALP URL for details)
• Session and Application and global.asa file. 
  • The global.asa file is supported without only the type library import option. This includes the Session_OnStart and Application_OnStart events, <OBJECT RUNAT=SERVER ...> with scoping. The type library (in ASP the constants from type libaries can be imported in global.asa - for example the ADO constants) import can be easilly replaced by using include files with constants. This feature is not planned for support or if added in future version it will not fully resemble the MS ASP. This is because ALP may run also dynamically (as autorun application for example) and the parameters required to import type library (its GUID) are cannot be known in such a scenario.
  • Session and Application have two collections StaticObjects and Contents (dynamic values collection).
• Scripting languages - ASP-like pages may be written in one or more languages. Using the SCRIPT RUNAT=SERVER tag you can mix the scripting languages as needed. By default ALP is configured to support VBScript and JScript/Javascript, but additional languages (other than JScript and VBScript) can be hosted by the ScriptGen if they are installed on the system and configured. Portable applications should redistribute any such languages  because they are not preinstalled with the Windows or IE (for example PerlScript, Pyton etc.).
• Binary transfers - Supported for the output and input. 
• Transactions and related features - ALP targets cross Windows platform portability and the Transaction server is not installed by default on all the platforms. Providing hardly integrated support for the transactions will make ALP dependend on it and thus will limit its portability. However the transactions are used mostly for server side optimization and they should not be used as widely in ALP. 
• Headers - Only MIME type (Content-Type) and Content-Disposition headers have meaning with ALP - the other headers are currently accepted but ignored. There is no universal headers support in the pluggable protocols API and only a minimal set of headers can be supported without simulation. 
• Cookies - not supported. A decision has been made to include such support for the ALP version after 1.2 (not including 1.2), but it will be more complicated than in WEB environment in order to avoid the potential problems caused by the fact that the HTTP cookies are not designed for the scenarios in which ALP runs. In general the cookies are defined in the Internet standards over the fact that the WEB servers have well-known constant addresses/names. ALP is too dynamic to be able to just simulate this without additional information (such as settings that allow ALP to recognize one site even if it has been moved). 
• Multilanguage support. With version 1.2 ALP supports all the languages that can be represented in multibyte charsets. Using the @CODEPAGE directive and the Session.CodePage property the pages can be designed to support any installed language. Note that in ALP these settings are more important than on IIS for ALP is designed to support even the oldest Windows versions and cannot afford to employ some of the features implemented in IIS only for the latest Windows OS versions. So, ALP is more sensitive and if you are working with non-european language, setting these options should be your first job. 
• ASP objects. The IIS developers know that there is way to build COM objects exclusively designed to work in ASP environment - with direct access to the ASP objects (such as Request, Response etc.). The old-fashioned technique - through OnStartPage/OnEndPage events is supported, but the classes built should use IDispatch (Object or non-specified type in VB) to fetch the ScriptingContext object and the other ASP objects. The COM+/Transaction server based technique is not supported as it will rise the ALP deployment requirements.
• Adjustable compatibility. In the way of the ALP development we made some little mistakes in the implemented behavior of some of the ASP objects and collections (for example the ALP 1.0 returned Null for the unset Session values). To provide compatibility for the both - application older ALP versions and maximum IIS compatibility it is possible to set a compatibility level for each application in its alp.application configuration file (or through the ALP settings shell extension invoked for the corresponding ALP site/application).