ALPDUMP supplementary protocol.

It is often true that many programming problems can be solved just looking at the input parameters. ALP engine supports additional protocol - alpdump that allows the developer to see how its script/program will be executed. Instead of execution alpdump: protocol shows the environment that will be used to process the request.

alpdump: works just like the alp: protocol and the same URL can be used by replacing the alp: with alpdump: in order to display the environment dump. For example URL alp://c:/site/my.asp can be changed to alpdump://c:/site/my.asp.

Output contains several parts:

• URLCALC - URL Parser: Translated parts of the URL and paths to the site, application and resource
• Loaded configuration files: Contains the three resulting configurations that will be used for the request - site, application and directory. These are the results after mixing the local and global configurations.
• REQUEST DUMP: Contains the information that should be passed to the content generator.
• Loaded modules: Count of the loaded Jacked modules - corresponds to the LIBRARIES section in the global alp.site file.

In addition alpdump can be used with relative URL - example:

If you have a form with action parameter:

<form method="POST" action="path1/path2/cgi.exe">

change it to:

<form method="POST" action="alpdump://!path1/path2/cgi.exe">

The string after the "!" character will be treated as a relative URL as in the original but alpdump: protocol will be used. The same technique can be used with relative URL in a hyperlink.

ASP pages source code

ViewSource record entry in the ScriptGen configuration allows displaying of the resulting source that will be executed. By setting it to 1 ScriptGen will not execute the ASP page but will display the source as it appears after parsing instead. Used as temporary setting it can help to find some specific errors.

Undoubtedly the most useful setting for ViewSource is 2. In case of script error the source of the page is generated again and the error line is marked in red color.

Generate file: protocol links in the pages

It is always recommended to point the bigger files that the user would like to "download"/copy not using alp: protocol but using file: protocol instead. You will need to do so in case of link showing the directory as a shell folder (not directory list generated by the DirList component). You may want to allow the user to open the directory and do something there.

File: protocol URL can be generated from ASP-like scripts using the Server.MapPath method:

<A HREF="file://<%= Server.MapPath(".") %>">view directory</A>

The example link above will open the directory containing the page in the same window. Resource from the ALP application site can be pointed:

<A HREF="file://<%= Server.MapPath("/files/sample.zip") %>">Get the samples</A>

The link above will cause download window to be shown and user will be able to specify the location where the file will be copied.

Internet Explorer "knows" that file: protocol URL points a resource from the local file system and optimizes the operation. It allows the browser to understand that cache is not needed and that the resource can be used from its location directly. The same technique will be good choice if you want to allow the user to open some kind of document such as MS Word document or a PDF file. If the file is a static resource (i.e. not generated dynamically by some other ALP script/application) this will prevent creation of a temporary copy of the file and spooling the file content to the browser through the memory buffers. Note that RawSpool component uses some tricks to avoid creation of copies but it still needs memory buffers in order to obey the standards.

In CGI applications you are able to use similarity between alp: URL and the local path pointed by the URL in order to generate the file: protocol URL. The simplest way is to use file: instead alp: namespace while generating absolute URL. The algorithm will be the same in both cases.

Determining the kind of environment - WEB server or ALP

Environment variable SERVER_SOFTWARE is available for the script through Request.ServerVariables collection and through the environment variables for the CGI applications. It contains the name and the version of the software processing the request. ALP fills in that variable the following string:

newObjects-ALP/1.0 or newObjects-ALP/1.1

You can check for the string "newObjects-ALP" starting at the first character in order to be sure that your application runs under ALP. Some of the components add more information to the string in format:

Engine/Version; NativeApplication/Version

Here is a simple function that can be used to do so in scripts:

        function IsTheScriptRunsOnDesktop() {
		var execContext = new String(Request.ServerVariables("SERVER_SOFTWARE"));
		var arrDesktop = new Array("newObjects-ALP","newObjects-ALPI");
		for (var i = 0; i < arrDesktop.length; i++) {
			if (execContext.indexOf(arrDesktop[i]) == 0) return true;
		}
		return false;
	}

The second name newObjects-ALPI is used only for the example. The function uses array of engine names inorder to be able to check for several desktop WEB engines (if they appear in future from other vendors). And similar function in VBScript:

        Function IsTheScriptRunsOnDesktop
		Dim I,execContext,arrDesktop(2)
		execContext = Request.ServerVariables("SERVER_SOFTWARE")
		arrDesktop(0) = "newObjects-ALP"
		arrDesktop(1) = "newObjects-ALPI"
		For I = 0 To UBound(arrDesktop)
			If InStr(execContext,arrDesktop(I)) = 0 Then 
				IsTheScriptRunsOnDesktop = True
				Exit Function
			End If
		Next
		IsTheScriptRunsOnDesktop = False
	End Function

See also the context ASP examples.