If you have some experience in the WEB applications development area you
already have most of the skills you need. If you also have at least a little
experience with the desktop programming, for example a little VB knowledge this
will help you understand ALP techniques in depth. The "HowTo" pages in
this section of the ALP site will show you how to start, how to use certain
programming techniques and other interesting details about ALP.
In this first page we review shortly the general concepts behind ALP and its
aims. If this is your first meeting with ALP it will be helpful to start
here.
The main goal of ALP is to combine desktop programming and WEB
programming. Doing this by adopting a desktop oriented language or a tool will
be hard if not impossible, while adopting WEB techniques for the desktop is
much easier and also benefits of the already existing tools and developer
skills. In fact everything we need is something that will do the WEB server's
work in the background of the application, but will not require network
functions from the operating system. You can call it "WEB server
simulation" or a "fake internet protocol". Microsoft Windows
already has the features that allow such software products to be built and the
logical decision is to employ them. This is what ALP does in general.
ALP is a modular pseudo server which is invoked through the alp://
protocol. The alp:// protocol is a "fake" internet protocol, it is
registered as like the other protocols - like http, ftp and so on. However
when invoked the system loads the ALP core component which does all the
processing locally in the invoking process. No network actions are actually
taken - this means that even without functional TCP/IP stack the alp://
protocol will still work and the user will have the experience of a working
WEB server on his/her machine.
If you take a look at the URL of the pages shown through the alp://
protocol you will see that they contain a local physical path instead of DNS
name and path on a remote server. However ALP treats the different parts of
this URL just like a WEB server will do - e.g. in an URL like this: alp://C:/MyDirectory/AnotherDirectory/page.asp
the part C:/MyDirectory/ may be presented to the ALP applications like
a host name and the rest can be presented as the path on the server (virtual
path). Why and When? To allow the applications running through it feel
comfortably, ALP needs to give them certain pieces of information typical for
the WEB applications. ALP presents certain characteristics of the URL and the
local file system structure in place of the typical for the WEB server terms.
For example, part of the URL is presented as server name, the rest is path in
the site, environment information is generated to indicate the running script,
its query line parameters and so on. Therefore much like the true WEB servers
ALP supports such features like: virtual WEB site (called in ALP "ALP
site"), ASP application (called in ALP "ALP Application")
and minimal directory settings (like read, execute, browsing access).
Apparently ALP needs some configuration settings which will define what is
ALP site - in which directory it begins, what is ALP application and in which
directory it begins. Do not look for them in any kind of a central
configuration store (like the metabase in IIS)! These settings are placed in
the file system instead - in the places for which they apply. This means that,
for example, an ALP site (virtual WEB site equivalent) is defined by saving
certain settings into the directory that will become the root for the virtual
site. The same is true for the other settings (application and directory
settings). ALP uses alp.site (for the virtual sites - ALP sites),
alp.application (for the ASP/ALP application settings) and alp.directory (for
the directory settings). There are so called "default/global files"
containing the default settings which will take place if the corresponding
file or a setting in it is missing in the location pointed by the URL is
missing. To help ALP calculate the major features of an URL even the mere
existence of one of these files in a certain directory tells ALP that the
directory has a special role. For example if (even an empty one) file alp.site
exists in a directory it becomes a root of an ALP site (virtual WEB site) and
all the directory tree under it looks for the application in it as subfolders
of the site.
There are certain benefits of keeping the settings in files in the same
location where the application files are (ASP files for example). This allows
the application files and the ALP settings share the same directory tree and
as a result the application can be copied together with the settings by
copying its directory tree (beginning with the directory that contains the
alp.site file). In other words you can get one virtual WEB site (ALP site)
move it to another place on your hard disk and it will remain intact - only
the URL to access it will be different, but the settings and the application
files will be ok. So, as long as you not hardcode any physical paths in your
code the application's actual physical location doesn't matter. IIS developers
will notice - this is not the case with IIS. In it you have centralized data
base managed through the administrative tool. In it you configure the virtual
sites, directories, applications and if you move the application somewhere
else you need to update the configuration too. While in IIS this makes sense
because having this machine wide configuration cached in memory will speed the
performance, in ALP flexibility and ability to move the application is a
primary concern. In ALP you have only one consumer - the local user, but in
IIS you may have thousands.
An example of how to work with ALP configuration you can read in the next
chapter "Configure ALP".
The programming interface. ALP's primary programming interface is
ASP compatible pages (Active Server Pages). If you have experience with the
classic ASP you already know there is a little you can do in ASP not using external
components. Without ADO, FileSystemObject and others you can just create some
basic pages, but nothing really useful. The ASP is a framework that gives you a
programming language and basic environment objects, but you need access to the
"outer world". ALP implements an ASP compatible environment, but from
that point further you need components to do different tasks. Like in the ASP
on WEB server these components are external and are not part of the core ASP
environment. However ALP applications are intended to work on different
machines after a short installation or even on-the-fly from an autorun CD or
flash memory card. Unlike the WEB servers where you or the administrator can go and
install what the application needs, you cannot go to every user location and
install all the components your application needs. Therefore ALP must offer
solutions:
The traditional way is to carry the needed components with the application
and install them on the user's machines. The ALP setup utility - ALPInstal can
do this for you (see its chapter). However, something can be done to help the
applications - provide them with a standard ALP run-time library they can
always count on.
The ALP Run-Time library is a wide set of COM objects the ASP pages can
create and use to perform their work. The objects from the library are created
the usual way - through Server.CreateObject or using the <OBJECT RUNAT=SERVER ...> tag. The
run-time library contains about 50 classes which cover wide range of features commonly
available in all the Windows versions beginning
from Windows 95: Unified programming interface for access to the file
system, memory blocks and network abstracting them all as streams and storages
providing text stream, binary stream and record based access over any of them
regardless of its nature, various script hosting objects including running
Active Scripts in background threads, system and file information facilities,
various conversion and direct data manipulation objects, string formatting
compatible with the C standard printf format specification with useful
extensions, abstract data management, persistence and transfer objects,
embedded SQL database engine (independent of ADO, Jet and OLEDB) and many
others. See Using the ALP run-time library
for startup information on using the library. If you stick to the ALP
run-time library even if you have equivalent components from other vendors you will not have
to care about the availability of the components you use. Porting pages
using similar components is simple because the similar features means
similar behavior and you need just to correct a little some method calls,
some parameters to them but there is no need to change the general logic. For example application that uses FileSystemObejct can be
changed to use the Storages and Files set of components from the ActiveX
Pack1 to access the file system. You will need just to make changes like this: change
fso.OpenTextFile(filename) to sf.OpenFile(filename) or file.ReadLine to
file.ReadText(-3) etc. Your porting work will be rewarded by the fact that
the ActiveX Pack1 provides text, binary and record based access to files
(and file like objects - such as OLE storages and network connections) on the
other hand FSO allows only text access and only to files! So, your application will be ready to accept changes that will
allow it to do more.
If you are concerned about using the code written for ALP in classic ASP
environment (Microsoft IIS based WEB server) using the library will not
prevent you from doing this. The library is also available separately as newObjects
ActiveX Pack1 and can be installed on the WEB server machine so that the
ASP pages can use it just like in ALP.
