Input/output of the ASP pages
(and the raw scripts) is done through the built-in ASP objects: Request (input) and Response (output). These two objects are
available to any executing ASP page and by using the features provided
by them the page determines the details about the request sent to it
and composes the result - response.
All the HTML content (or other
textual content in case of non-HTML page) is translated by ALP to a
Response.Write calls. You can see what is really executed after parsing
by changing temporary the ViewSource value in
the alp.application to 1. This will show the parsed script ready for execution instead of
Request - Input
The ASP pages are using the Request object collections to
access the data passed through the request. These collections contain the:
the URL after the "?" sign (QueryString
values entered in the form if form submit is used in the HTML
design of the page (Form collection)
environment information (ServerVariables
collection) - various entries giving the page information about
its location and the conditions under which it is executed.
For example when the user clicks a submit button of a form browser encodes its content and
"posts" it to the ALP. Form fields are several types but all they have
textual values only. Further conversion to a numeric type can be made by the
page as needed. Or in the more simple case of a link the user clicks a
text hyperlink or an image hyperlink and the request specified for the
link is sent to the ALP engine.
Lets consider the links first. Usually a hyperlink is coded
in HTML in a way similar to this example:
The user sees a text label over which the mouse cursor becomes a
hand and if the user clicks over it the contents of the HREF attribute
is translated to full URL and sent to the ALP engine. All the text
after the "?" sign is treated as parameters which means that
this part of the string is parsed by the ALP engine and passed as a
collection of parameters to the executed page (page.asp in the above
example link). So, the ASP page can access the above sample parameters
' Link Sample 1
variable1 = Request.QueryString("Param1")
variable2 = Request.QueryString("Param2")
Response.Write "Param1 is: " & variable1 & " and Param2 is: " & variable2
The obvious question one would ask is what will happen if the same
parameter name is used more than once. As it is seen above the
parameters are passed as pairs ParameterName=ParameterValue.
The ParameterName is used as a key for the value in the Request.QueryString
collection. There is no restriction about using the same parameter
name more than once in a single URL. When it happens all the
parameters with the same ParameterName are put under the same
key - if we have:
Then Request.QueryString("ParamX")(1) will return
Value1 and Request.QueryString("ParamX")(2) will
return Value2. Thus for each parameter ALP creates a sub-collection of
the values passed through the URL with the same parameter name. In
fact even if the parameter name is used only once the value is only
one ALP still packs it in a collection, but it has one element only.
If we return to the first sample link:
' Link Sample 2
variable1 = Request.QueryString("Param1")(1)
variable2 = Request.QueryString("Param2")(1)
Response.Write "Param1 is: " & variable1 & " and Param2 is: " & variable2
And the result will be the same as before. This is so because the
sub-collection that holds the values for a particular parameter
returns its first element if no index is specified. However the
developer should be aware that Request.QueryString("Param1")
and Request.QueryString("Param1")(1) return different
kind of results, no matter that in most expressions the difference
will remain hidden. The Request.QueryString("Param1") is
an object which holds a collection of values 1 or more depending on
how many values are passed with this parameter name. On the other hand
Request.QueryString("Param1")(1) is not an object but
a value (string value) because it explicitly extracts the first
element of the collection. Thus you can write safely:
Set v = Request.QueryString("Param1")
Set v = Request.QueryString("Param1")(1)
will cause an error because object is required by the Set keyword.
To determine the number of the values for a given parameter you can
use the Count property:
paramCount = Request.QueryString("Param1").Count
The collection is 1-based so For ... Next cycles that iterate
through it can be composed as:
For I = 1 to Request.QueryString("Param1").Count
The values are always strings and the page should convert them to
whatever type it needs, parse them in a developer chosen way and so
When the user clicks the button (not on this help page, of course -
here the form is just an illustration) the values entered in the text
boxes will be sent to the ASP page specified in the ACTION attribute
the same way as in the above link samples. I.e. the browser will
compose internally an URL with a "?" sign and will encode
the user input as Param1=Value1&Param2=Value2 assuming that
the user has entered Value1 in the first text box and Value2
in the second text box. The parameter names are the field names in the
HTML form (see the NAME attribute).
So, generally this kind of forms will produce request that for the
ASP page will look as like it came from a link. Even more complex
fields used in the form will not change anything (see the form fields
behaviors below for other details). This is very convenient when the
developer wants to preserve certain user form input in a link. For
example a search displayed in pages may benefit of this: The user
enters the search term in a form field, the results are too much for a
single response, then the page lists let say 10 of them and displays
links to page 2,3,4 and so on. The links can be generated with a
parameter named after the text box name in the search form and with
value set to the user input received and additional parameter
specifying the page number. Thus clicking the links the user will
submit the search again but will also request n-the page to be shown.
In general the links, URL-s entered manually in the address line,
forms with METHOD="GET" are called GET requests. In
such requests all the parameters are included in the URL no matter if
the URL is explicitly specified or the browser composes it internally
in response to a form submit. The negative side of this technique is
that the URL length is limited. In general the developers should not
use this technique if there is any chance that the total size of the
URL may grow over 2000 characters (the actual limitations may vary and
are bigger, but you must not count on exceptions if you want your
application to work correctly everywhere).
The POST forms.
When more data must be sent there is another technique - form POST-s.
If the field is part of a form when the user clicked the submit button browser will
encode it as:
Note that the space is "escaped" as %<hex_char_code>. All the HTML
fields no matter what is their type are encoded in the same way. The differences are
in the rules when their value is posted and when it is ignored:
TYPE=TEXT - text in the text box can be changed by the user. It is posted always.
TYPE=CHECKBOX - posted only if checked and ignored if not. If
checked the page receives the contents of the VALUE parameter of the
TYPE=RADIO - like the CHECKBOX but browser manages all the RADIOs with the same name so
only one to be checked at a time.
TYPE=HIDDEN - as the TEXT fields but it will not be displayed. Often used to save some
information through several requests not using the Session object.
TYPE=PASSWORD - as like the TEXT field but text in the box is displayed with
""" in place of every character.
TYPE=BUTTON - browser shows a button. Acts like the TEXT field but value can not be
changed unless the DHTML scripting is not used.
TYPE=SUBMIT - button like the previous but by clicking it user invokes form submit/post.
TYPE=IMAGE - allows SRC parameter to be specified defining a picture to be shown. Acts
as like the SUBMIT button in the forms but sends two values
FieldName.X=XCoorddinate&FieldName.Y=YCoordinate. That are the coordinates of the
mouse click that invokes the submit action.
TYPE=RESET - as like the BUTTON but when clicked it reverts the form values to the
initial default values specified in the page source.
Displayed as a combo box or as a list box. Only the selected values are sent.
<TEXTAREA NAME=MYFIELD>Some value</TEXTAREA> - as like the TEXT but
displayed as multiline edit box.
Determining if a particular field value exist in the posted data mean that the field is
not ignored. Thus for the CHECKBOX and RADIO fields this means that the control is
checked. or for the SELECT element determines the selection.
It is often comfortable to submit the page to itself. The page may put the received
values in the form processing the input and thus allow the user to make new changes and
re- submit them again (e.g. there could be options specifying details
about the action that must be performed).
There are two form methods POST and GET (where GET is default if
nothing is specified). In the both cases the browser encodes the
values the same way but it sends them to ALP in different manner. In
case of GET method the data is sent as part of the URL (the query
string), while in case of POST method it is sent as a stream of data.
Because of the browser query length limitations the POST method should
be used wherever considerable amount of data is transferred. While
most browsers support more a good limit will be 1000 - 1500
characters. On the other hand GET method can be easily represented as
regular link with many query string parameters. This makes it very
useful when you need to transfer some of the data user submitted
initially through several pages - for example paging a db report
showing will benefit if you can place links to page 1,2,3 etc. The
implications are that the usage of the form methods should be
The form syntax is:
<FORM METHOD="GET | POST" ACTION="scripttoprocessit">
... HTML and fields ...
see details about the HTML syntax in MSDN or other HTML reference.
See the following samples:
Forms (samles\asp\simple\Froms_JScript asp and samples\asp\simple\Froms_VBScript asp)
Enum (samples\asp\simple\Enum_JScript asp and samples\asp\simple\Enum_VBScript asp)
Request object has a default property that allows the programmer to refer to the any
collection containing the desired value and thus make the script independent on the used
method for the form submission - see Request object.
Binary input, uploads and so on.
The input techniques above are good for parameters and user input but
are not suitable for sending binary information such as files for
To support this a form in a HTML page must be configured to send
encoded multipart data - which means binary stream with parts
containing different kind of data separated from each other and also
described with some headers. This allows normal form fields and binary
data to be mixed in one form submit. Here is a simple example of such
<FORM METHOD="POST" ACTION="somepage.asp"
... form fields ... for examle:
<INPUT TYPE="FILE" NAME=F1>
... and so on ...
As like the classic ASP ALP provides the posted data to the page
through the Request.BinaryRead method. Unlike the regular forms the post
is not parsed and placed in the Request collections. In general this may
be considered as inconvenience, but there are reasons. Usually the
binary posts are much bigger than the regular forms. Sometimes megabytes
of data are posted at once. Combining convenience and universal
flexibility will require a lot of memory and other system resources
while in many cases the page may need only a little part of the posted
information. Thus the page is left to handle the binary input on its own
and thus optimize the processing as possible. In ALP you have all the
tools needed to construct any binary input processing. See the Upload
samples packed with ALP for examples on how this can be done. There are
many ways to handle huge amounts of data - they can be stored in memory
for further processing, can be partially stored in memory and partially
kept in temporary files or other streams - with the ALP
run-time library (see the SFMain, SFStream objects) you can process
even non-standard postings (not coming from the browser for example).
See the samples descriptions for more information about handling
Output of the textual or HTML content can be made by explicit call to the
Response.Write method or using the <%= %> tags. These tags can help to embed the
code into the page without too much code writing.
<% @Language=VBScript %>
Passed values with name MyField are:<BR>
<% For Each I In Request("MyField") %>
<B><%= I %></B><BR>
<% Next %>
will show all the values of the fields with name "MyField" from the form
submitted to the page.
While in classic ASP the usage of too much <%= %> tags is often
considered as performance slowing technique in ALP it has much less
effect and the developer convenience can be followed - ALP runs on the
client machine and serves only the local user.
Binary output: You can use Response.BinaryWrite to serve non-textual
data. In such cases you must take care to set the correct Content-Type
so to help the browser recognize the output.