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
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.
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
- 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
- URL - (See above notes too). ALP URL syntax is designed to
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
- 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
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
- 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
- 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
- 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