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 executing it.

Request - Input

The ASP pages are using the Request object collections to access the data passed through the request. These collections contain the:

• parameters from the URL after the "?" sign (QueryString collection)
• 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:

<A HREF="page.asp?Param1=Value1&Param2=Value2">Link text</A>

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 this way:

' 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:

<A HREF="page.asp?ParamX=Value1&ParamX=Value2">Link text</A>

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:

<A HREF="page.asp?Param1=Value1&Param2=Value2">Link text</A>

we can refer to its values like this:

' 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")

but

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 forth. 

How the HTML forms behave?  

Lets consider this form first:

<FORM METHOD="GET" ACTION="page.asp">
  <INPUT TYPE="TEXT" NAME="Param1" VALUE=""><B>
  <INPUT TYPE="TEXT" NAME="Param2" VALUE="">
  <INPUT TYPE="SUBMIT" VALUE="Click me">
</FORM>

This will display to the user like this:

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. 

How the different input fields work?

<INPUT TYPE=TEXT NAME=MYFIELD VALUE="Initial value">

will display as:

If the field is part of a form when the user clicked the submit button browser will encode it as:

MYFIELD=Initial%20Value

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 field.

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.

<SELECT NAME=MYFIELD>
  <OPTION VALUE="Value>Text
</SELECT>
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 considered carefully. 

The form syntax is:

<FORM METHOD="GET | POST" ACTION="scripttoprocessit">
... HTML and fields ...
</FORM>
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 (samples\asp\advanced\Request_JScript.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 example. 

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 a form:

<FORM METHOD="POST" ACTION="somepage.asp" enctype="multipart/form-data">
... form fields ... for examle:
  <INPUT TYPE="FILE" NAME=F1>
... and so on ...
</FORM>

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 multipart data.

Output

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.

For example:

<% @Language=VBScript %>
<HTML>
<BODY>
  Passed values with name MyField are:<BR>
  <% For Each I In Request("MyField") %>
  <B><%= I %></B><BR>
  <% Next %>
</BODY>
</HTML>

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.