Technology overview. 

The ASP pages is the primary programming technique in ALP. It is simple and easy to learn. Even developers with no experience in similar technologies would be able to learn the basics for hours and begin developing their own applications with ALP. The ASP is extensible and needs from the developer to know the basic techniques and syntax only, any further details can be learned when needed and ignored when the application being written doesn't need them. 

The term ASP comes from 'Active Server Pages" introduced in Microsoft Internet Information Server. ALP implements on its own Active Local Pages technology which is very similar in the means of usage, but is also different because it is especially designed for development of desktop/stand-alone applications running on the user's macine.

Although ALP targets scenarios different from the scenarios targeted by a WEB server it preserves and employs the same techniques. These techniques are in the first place convenient and easy to program in form oriented applications. These are applications in which the user interacts with the application by filling/altering the contents of forms, tables, lists. On the other hand this gives the developers one more important benefit - the ALP pages are by default almost fully compatible with the Active Server Pages technology and almost always an application written for ALP can be deployed on Microsoft IIS WEB server without need of changes in the code! Because of this compatibility we will refer to the ALP pages as ASP pages.

The request-response abstraction

The Request-Response is a kind of Client-Server technique. It can be characterized as a pure Client-Server in contrast to the majority of the technologies which are client-server, but still allow part of the work to be done on the "client" side without interaction with the "server" side.

ASP is a Request-Response technology where on the client side the user uses a viewer (usually WEB browser) and on the content shown in the viewer is generated on the server side. The user interacts with the application by "submitting" requests and receiving "responses". Thus the user actions, for example clicking a button or a link, lead to requests sent to the server which returns a response content which changes what the user sees in his/her viewer/browser. So, the user sees an user interface in the viewer, what he/she sees is defined by the content displayed by the viewer. Usually this is based on HTML and the WEB browser draws the HTML on the user's screen allowing him/her to view it and perform certain actions which will lead to request-response pair of background actions that will change the HTML content displayed in the viewer/browser. While it is not yet popular, it is not impossible to use ASP with ALP and IIS and non-HTML/XML based viewers and content. 

Considering the above a brief comparison between ASP and a typical form based development tools such as Visual Basic, Delphi and many others, points out one significant difference: In the traditional form based development environments the form shown to the user has more or less static base structure and the client-server applications change the contents/values of some elements of the form when the user invokes certain actions. In ASP (and especially ALP where the conditions under which the application works are the same) the entire form is replaced each time the information shown in it needs to change. Thus in ASP the interactions with the server have more clear effect - the user sees a "document" displayed by the viewer and when the user does something the document changes/re-generates.

Still, we should not forget about DHMTL here. If DHTML techniques are used in the displayed document the application may implement certain functionality on the client side and avoid full regeneration of the entire document presented to the user when the user action can be serviced without need to contact the server.

Client and server - where are they?

In a traditional form based software development environment the client is usually the application code that controls the form presented to the user, and the server is usually a database engine - sometimes remote, sometimes embedded and actually part of the same application that is otherwise a client. So, the separation of the client and the server is mostly logical and ALP is not an exception. In ALP the client side is the document code (HTML or XML) code displayed by the viewer/browser and the server side is the ASP code that generates this document code. If we include a database in the picture we can even think of the application as of a 3-tier application where the database is the 3-d layer. As in the case of the other environments all the layers may be in single application separated only logically, but of course they can be separated in different processes and even on different machines. Thus an ALP ASP application which runs on a stand-alone machine and uses the for example the supplied ALP embedded database engine (See SQLite COM) will combine all the layers in a single monolith application. Still the logical separation of the layers is very clear and the same application can be distributed on 3 separate machines - the client side (the viewer) on the user's machine, the ASP processor on a WEB server machine and the database server on another machine. Because of the compatibility with already popular technologies and the clear boundaries of the different layers this is simple and very often can be done for minutes. In contrast an application based on traditional form based development environment will need substantial effort and often will need to be fully re-written in order to deploy on separate machines. Thus the ALP applications are almost automatically publishable on the WEB in fully functional condition. 

ASP concepts, structure and syntax

If you are new to ALP and ASP you can learn how to write applications in just a few moments. Follow the topics below to learn how to write pages, how to integrate them in one application and how to perform actual tasks by using the components supplied with ALP and 3-d party components. 

The ASP page structure

When we speak about an ASP page, we assume by default the basic building block of the ASP applications. The single ASP page combines the document code (usually HTML or XML), script code that generates/replaces parts of the document code and is designed to service single request by generating the response document code which is then displayed in the viewer/browser.

Additional reading: Active scripting concepts and ALP.

Interaction with the user

The ASP pages receive the request as s set of values grouped in several collections. They represent the details about the request, the user actions/selections involved in it. The ASP pages interact with the user by inspecting the request data and responding accordingly.

Application wide state the Application and Session objects

The ASP pages themselves have very short life-time. They terminate after responding to the request. However the applications need to keep and transfer some data and objects across the requests and refer to them from different pages when they service different requests. ASP strictly distinguishes 3 variable scopes - page (request) scope, Session (user) scope and application (global) scope. 

Initializing the application - global.asa file

As the separate ASP pages service single requests it is logical to have a special place for the application initialization. In the global.asa file the ASP applications can instantiate and initialize variables and objects for the session and application scope.

Using the components to perform the actual tasks

The above topics explain how the ASP applications work, but the applications can do a little useful work up to this point. To perform something of real use the ASP applications need components. The components are libraries that provide certain functionality to the application. The applications create objects from these libraries and use their members (properties and methods) to perform their actual work. Many components are designed to work together - e.g the page creates an object, then calls a method on it which returns another object, or the application creates two or more objects, initializes them and passes one object to another in order to cause certain action.

The ALP Run-time library. 

ALP supplies standard run-time library to the ASP applications. It contains components that give the applications ability to work with files, databases, network connections, organize their run-time data and persist it, run background threads and so on. However the ASP applications are not limited to it - they can use thousands of  3-d party components to gain access to more system features, access and control other applications working on the same machine, work with corporate database servers and so on. 

How to build components that will integrate with ALP

The ALP run-time library contains multipurpose components. They are used in ASP practically the same way they are used in other environments. Because they are universal, it is convenient to have them this way, but if the developer wants to build own specialized  components for certain ASP application(s) it is more practical to integrate them with ALP tightly and thus save some ASP coding and simplify their usage. This is most often useful for components implementing business logic over data processed partially in the ASP code, components that process part of the request and present it to the ASP code in more convenient form and so on. In such case it is useful to provide these components with means to access the ASP object model directly without need to write countless lines of code simply to transfer data from the request to the object.

The ALP developers can build such components in C, VB, VBScript/JScript and other COM enabled languages. Sometimes the very reason for building such a component is to benefit of a specific feature of a language not directly usable in ASP - this article explains how this can be done.