Begin with Active Local Pages (ALP)

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. 

What is ALP internally?

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.