This page helps the
developers learn Active Local Pages concepts and leads them through the basics.
Each topic is described shortly with links to the detailed
information. Reading the page you can get overall idea about the
meaning of each term and feature and dig into the details as needed.
This page is designed with the primary ALP programming interface in
mind - ASP
compatible pages. However most of the information here is also
applicable to the CGI programming and the other programming techniques available
in ALP. It is assumed that the developer has at least basic
understanding of the WEB programming concepts. However there are notes
throughout the page that should be helpful for developers without WEB
programming experience.
ALP is a client-server programming environment. The viewer
(usually Microsoft Internet Explorer or ALPFrame) is the client and
the ALP engine is the server. They work in the same process and user
may never know about this, but it is easier to understand ALP if you
think of it this way. Furthermore ALP is request-response based.
This means that the applications work by performing clearly
distinguishable request-response actions. Thus every interaction
between the client (browser) and the server (ALP Engine) is
characterized by an ALP URL. The ALP URL looks like this:
alp://C:/directory1/directory2/.../file.ext
The parts of the URL are:
alp:// - the ALP protocol scheme name
C:/directory1/directory2/.../file.ext - Physical path to a
resource (file). Note that ALP also supports back-slashes, but the
canonical form is with normal slashes.
The physical path part is logically cracked in 3 parts by ALP
internally - Virtual ALP site, virtual path in the site and a
file/resource name. We will discuss the logical parts later in this
page and the details can be read in ALP URL..
When the ALP engine receives the request it determines the what kind
of resource is pointed by its URL and processes the resource through
the internal ALP module associated with this resource type. For
example if it is an image it is simply send back to the browser as
binary stream by the trivial (Internally called "Raw
spool" module). If it is an ASP compatible page the ALP's ASP
module executes it and the page generates the content which is sent
back to the browser.
Thus aside of the trivial resources the application code (assume
ASP page) typically behaves quite simply - it generates textual or
binary content which ALP transfers back to the browser. The ASP page
can be designed in different manners, but in general it allows the
developer to put in it static and active parts when
the page generates HTML, XML or other textual content. Thus the
static parts need no code while the active parts are generated by
the program code in the page. Lets illustrate this with a simple
page:
<HTML>
<BODY>
<H4>This is a sample</H4>
The time is: <%= Now %>
</BODY>
</HTML>
Most of this sample page is static and only the date/time depends
on the moment in which it is executed and needs to be active.
Furthermore the static parts may be repeated if they occur between
active parts of code that implement a cycle:
<HTML>
<BODY>
<H4>This is a sample</H4>
<% For I = 1 to 7 %>
<P> Hello World! #<%= I %></P>
<% Next %>
</BODY>
</HTML>
Note that the samples In this chapter we intend to give you basic
understanding of the ALP concepts, you can learn how to write ASP
page in Writing ASP pages for ALP.
The ALP URL may contain also inline parameters. These are called
Query String parameters and are send as part of the request's URL.
For example we can add some parameters to the above sample URL:
alp://C:/directory1/directory2/.../file.ext?param1=value1¶m2=value2&...¶mn=valueN
These parameters are only parsed by the ALP engine and the
resource is responsible to process them for its own purposes. Thus
if the resource is an ASP page ALP will do nothing more than to pass
the parameters to it. If the page will use them for anything is up
to the developer who wrote it. Lets take an example:
If an ASP page is invoked with this URL:
alp://c:/dir/page.asp?MyParameter=MyValue
The page can do this for instance:
<HTML>
<BODY>
The parameter is: <%= Request.QueryString("MyParameter")
%>
</BODY>
</HTML>
Which will put the parameter value in the content returned back
to the browser.
HTML allows the developer put links which the user may click and
thus invoke request to be send to the ALP engine. The links are
defined in HTML with the <A> </A> (anchor) tags. For
example <A HREF="_url_">Text to display</A>.
The _url_ parameter in the HREF attribute can be an ALP URL with or
without inline parameters. Thus the developer can generate HTML that
shows certain links to the user and allows him/her to invoke new
request with some predefined parameters or/and to invoke other ASP
pages or other resources. Of course this is good for tasks where the
number of choices the user can made is low and predetermined. If the
user should be able to enter random information or make complex
selections from lists, checkboxes and other user interface controls
the HTML supports forms. The forms may contain different kind of
user interface elements such as drop down lists, lists filled with
elements, text boxes, text areas, check and radio boxes, hidden
elements. The user may fill and make selections in the the form
elements and submit the form as whole. This will send a request in
which besides the URL ALP engine will receive also the form data
filled by the user. As the ASP page generates the form definition
HTML code it is able to generate it with pre-defined default
entries, number of options between which the user may choose and so
on. This gives the application ability to receive from user whatever
input is required. Still the developers with no experience in the
WEB programming should notice that the forms are always submitted as
whole - they cause request to be send to the ASP engine and the
resource specified in the form definition HTML when submitted. In
contrast in a form based RAD environment the form processing may be
not so straightforward. Let's take an example:
A simple form like this:
<FORM METHOD="POST" ACTION="mypage.asp">
<INPUT TYPE="TEXT" NAME="MyField"
VALUE="Write something here">
<INPUT TYPE="SUBMIT" VALUE="Submit">
</FORM>
will display to the user like this:
The user may fill something else in the text box and submit the
form by clicking the button. Then the mypage.asp my access the user
input like this:
<HTML>
<BODY>
You wrote: <%= Request.Form("MyField") %>
</BODY>
</HTML>
There is another substantial difference between ASP page and a
typical program written in VB for example. The pages are state-less
- this means that the life time of an ASP page is from the moment in
which the request is received to the moment in which the page
completes its response. Writing the page you can use define
variables, functions and other program elements, use them but they
are all deallocated/lost when the response is sent back to the
browser. Also notice that the ALP application can be composed of
several ASP pages. Each page may generate content that contains
links and forms that invoke another page. Thus the application
logically consist of all those pages. As all the page variables and
routines are private to the page the pages may pass information to
each other by generating parameters in the links or hidden fields in
the forms, but while this is convenient for some simple tasks there
is a need of something more. This need is satisfied by the so called
Application and Session objects. In ALP Application and Session
almost overlap as functionality but for compatibility reasons with
ASP on IIS ALP supports them both. These objects are data and object
stores where the pages can save values and objects that should
remain accessible to the other pages in the application and
throughout the requests.