• ALP and Java
• What kind of CGI programs can be executed and what languages are available through CGI interface?
• What about the ALP redistribution files ?
• How to check and update the local system
• Embedding visual controls which lack of custom protocols support
• Using Macromedia Flash

ALP and Java

Java applets initialization fails with Null pointer exception if page is opened through ALP but they are OK if loaded through file: protocol.

This happens because Java uses internal classes for the asynchronous protocols and ALP is not known for the Java machine. Walk around is possible:
Revert your page to asp (if it is a pure html page) and place CODEBASE attribute in the APPLET tag. For example:
CODEBASE="file://<%= Server.MapPath(".") %>"
It defines as base path for the .class file (or java archive) the directory containing the page. If your classes are in some other place on the site - pass the virtual path to their directory to the MapPath.
Thus Java applet is loaded through well-known protocol for the java engine - file protocol.

Navigation Java applets are unable to open ALP URL or relative URL.

This is a design problem of the Java architecture. Applet communicates with its host through AppletContext interface. It uses the showDocument methods. These methods allow the applet to instruct its host to navigate to another URL. But URL argument is of URL type - not a String. Thus initialization of such kind of object can not be done without the appropriate protocol classes. Thus every protocol unknown for the Java machine can not be used to navigate with the browser (why Java must be able to work with the protocol in order to command the browser I don't know but probably Sun knows).
Here is a page with applet that shows the problem (click here). Try other protocols - such as about: and res: - they will cause Java exceptions too. Providing ALP protocol classes for Java is not in our urgent tasks list, but if many users demand that we will do it. The problem that can not be solved is running such stuff (ALP protocol classes for Java) without installation - it seems to be impossible thus portable applications should not rely on such features.

Support for Servlets and JSP

It is not in the urgent list but we have plans to implement these technologies at later time. Of course they will not be able to run without installation (some of the required Java classes must be installed) and this is one of the reasons to leave this task for a later time.

What kind of CGI programs can be executed and what languages are available through CGI interface?

Although ALP doesn't support as native modules all the WEB programming technologies, some of them can be used through CGI interface. For example Perl interpreter can be started as a processor for CGI scripts with extension of your choice. The same can be done with most languages available as executables intended to run as CGI script processors and also many other languages not especially designed to run as CGI can be configured in ALP application. ALP CGI processing module supports very extended set of configuration settings for the purpose - in the examples you can see WSH and cmd.exe used as CGI processors.

Sometimes one of the ALP architecture requirements can be a problem. Parameters to the CGI scripts must be in the popular query line format known from ASP, PHP, JSP and many other WEB programming tools: ...?parameter1=valueśmeter2=value2... To determine compatibility of a particular language/tool check if it fits in that limitation. In many cases the problem can be walked around. If you have problems please ask - this will help us too!

ALP redistribution files

Registered customers of the ALP have access to the retail version of the ALP and currently two redistribution packages:

• Package that installs the ALP engine and the viewer with setup utility that can be configured to include additional components and the entire application. Configurable through a structured configuration file.
• Package for running ALP without installation through ALPFrame viewer only. Most suitable for auto-run solutions and other situations in which application wants to run immediately.

The first package is a down-stripped version of the full ALP archive containing the vital components only. The second has the same contents but without a setup utility in it. Documentation explains details on how to manage the ALPInstall (ALP setup utility) advanced developers are able to prepare more complex solutions. As seen in the shareware version the setup utility has a minimal user interface and does not require the final user to select any settings. It asks questions only if some files have to be replaced and version checking is not enough to determine is it safe or not. That makes it applicable for internal redistribution of of software components within the company and especially if you want a solution independent of the Microsoft Installer - feel free to use it not only with ALP.

NOSC (newObjects ODBC Simple Components) are not included but can be added through editing the install configuration. Make sure the target platforms have ODBC installed - if not the setup will issue warning/error messages - not fatal for the resting components. For example if you are sure the target machines are equipped with MS Office then you may assume ODBC is present and such a redistribution package (with NOSC included) will be suitable.

The same notes are true for the auto-run solutions. ALP applications are able to use many components. Thus before packing your application make an investigation which of them are available on the target platforms. If the situation seems to be hopeless because of unavailability of these components then you will need to choose installation way and redistribute those components with your application. We understand that most of the WEB developers have habits to work for well-known environments often administrated by themselves thus we will help with suggestions and ideas (we are WEB developers too), don't hesitate to ask your questions - this will help us to find what else is important to be done! Just please do it by e-mail or arrange a chat conversation if possible - English is not our native language and sometimes phone conversations are harder than writing ones.

How to check and update the local system

ALP applications may need some popular components for their work. Such components are ADO and related OLEDB providers, ODBC. Also if the application depends on the VBScript/JScript version or their run-time libraries (FSO and other component) you will need to check if the local system contains the required components and if not you will need to perform an update - or at least inform the user and give him/her the appropriate links. In the typical WEB programming environment the server system is managed by trusted administrators and all the required components are installed when needed but this is not the case with the end-user systems on which WEB application may run under ALP.

Here you can find some samples on what to do. The samples cover only the basic (widely used) components that the ALP application often needs. Instead of checking versions of every component on the system samples are very simple and they are designed to try to create the required components and in case of failure they show the appropriate links - to local files (on the application CD for example) or Internet URL. The two samples can be easily configured and used in your applications, but if you want more tests or another design - feel free to change them.

How to use and when? See the Readme.htm in the archive for more information on how to use them in your application. When? Such a solution is applicable for popular components - which can be found on most of the machines and only on a little part of them the update will be required. This means Microsoft DB components, Active Scripting languages and their support components, but this way is not applicable for components rarely used on the client systems. In that case you should include them in the application setup or ALPFrame configuration (if the components are able to run this way - see the ALPFrame documentation for more information). Also if you are building an application for wide distribution it is recommended to not depend on the latest versions of the Microsoft DB/Scripting components. Why? Because the newer versions are not fully compatible with the oldest OS otherwise supported by ALP itself. This means the latest trusted versions are: of the MS Data Access Components - 2.5, of Active Scripting - 5.1. Newer versions may cause problems on older systems such as Windows 95 or first editions of Windows 98 and NT4. Also carefully check the required script version and if 3.0 is enough for you do not force the user to install a newer one - there are many users using Internet Explorer 4.X yet and it ships with version 3.0 of the VBScript and JScript.

Download the samples (15K zip).
Note: the full ALP 1.1 package already contains more advanced sample which can check for DLL versions, availability of certain ActiveX etc.
The update page online - used by one of the samples in the archive.

Embedding visual controls which lack of custom protocols support

In general this technique is common for Flash, Java and any other controls/embeddings on the page (client side) that cause problems with ALP. Many of the embedded controls need to download resources ins order to work. For example a Flash control may need a .swf file, Java applet will need to download some classes etc. The HTML contains certain elements which give the developer opportunity to describe where and how the embedding will appear on the page. All these elements contain attributes (or refer to other tags) which describe the location from which these resources must be downloaded. So in the PARAM elements, SRC  and CODEBASE attributes developer most often specifies relative or virtual path to the resource file/directory on the site. When the browser activates the embedding it passes to it the full URL which is a result of combining the path specified in these parameters with the current page URL. For example:

The page is on http://server/path/page.htm
The parameter in an embedding on that page specifies a resource
/resources/some_file.ext
Then the embedding will receive the combined URL:
http://server/resources/some_file.ext

Or if relative path has been used:
The page is on http://server/path/page.htm
The parameter in an embedding on that page specifies a resource
some_file.ext
Then the embedding will receive the combined URL:
http://server/path/some_file.ext

From this point further the embedding is responsible for the download itself. Therefore how it will interpret the URL is up to it and The browser nor ALP may interfere with this behavior. Thus if the embedded control cannot understand what is alp:// protocol it will not even try to do anything and will fail.

How to walk around the problem?

The embedded elements on the pages use different APIs to handle the resource download. In most cases developers who've built them prefer WinInet or raw WinSockets. These APIs do not support custom protocols and thus they are able to fetch resources through http, ftp and file protocols only. So in ALP you can trick them by passing local file:// URL instead of alp:// URL. To do so wherever you are placing such embeddings you whould change the parameters pointing their resources to point the full local physical path instead of relative or virtual path to the resource. To do so you need to make sure the page is ASP page and use Server.MapPath to convert the relative or virtual resource path to local physical path. For example if you need to put relative reference to file like this:

resources/some_res.ext
you will need to change it to:
<%= Server.MapPath("resources/some_res.ext") %>

This will instruct the embedding to fetch its resource(s) through the well-known file: protocol and the embedding will work correctly.

If you want to avoid need of two versions of your pages you can implement a simple function in an include file which analyzes the environment and returns mapped or unmapped path depending on where the page works - under ALP or IIS. An example for such a function is included with ALP full package but here is a simple example on how to build it:

	Function CreateURL(s)
		Dim I,execContext,arrDesktop(1)
		execContext = Request.ServerVariables("SERVER_SOFTWARE")
		' Array of the known desktop softwares. 
		' You can add others if you need.
		arrDesktop(0) = "newObjects-ALP"
		For I = 0 To UBound(arrDesktop)
			If InStr(execContext,arrDesktop(I)) = 0 Then 
				CreateURL = "file://" & Server.MapPath(s)
				Exit Function
			End If
		Next
		CreateURL = s
	End Function

The file:// preffix is added before the generated local path. Although most of the controls will recognize local path without it placing it will not do any harm and may help with some controls which need it in order to determine the type of the URL.

Unfortunately this problem disturbs not only ALP. It also prevents the developers from using such embeddings in other custom protocol based environments. Popular examples are the Microsoft supplied HTML help, resource fetcher (res: protocol) and many others. As ALP is a programming environment you can use the walk around described above, in non-programming environments (such as HTML help) this is impossible. If you need some of them be concerned about the possible problems.

Additional suggestion for developers using any custom protocol based tools (not only ALP). Even if certain control works well you should not rely on it unless you have an official statement from its developer that custom protocols are supported. Official name for them is Asynchronous Pluggable Protocols. To use them a control should fetch its resources through URL Monikers. So this is what you must check before deciding if you will use the control and how you should use it. In ALP such an uncertainty will mean you should stick to the walk-around technique (even if the current version of the control works without it). See the notes about Macromedia Flash above.

Using Macromedia Flash

As like Java you may have similar problems with Macromedia Flash player controls. A more thorough description of the problem you will find above. We suggest you reading the above FAQ section before implementing any pages with Flash. As it is stated there you need to use the walk around technique described there. Here is an example on how you will need to change your HTML/ASP code to make the Flash control work (the important parts are in bold):

Original:

Should be changed to:

A more convenient implementation will deduce the hosting environment (IIS or ALP) automatically. Using the sample function from the previous FAQ section will allow you use the same code on the both platforms:

Of course you will need to place it in an include file or place it in the page's ASP code before using it.

Macromedia Flash once worked with ALP what happened? Yes in version 5 Macromedia used URL monikers to fetch the resources, but unexpectedly without any notice they removed this support from their control in the 6-th version (or a minor update after it we are not sure for the exact version). So the Flash controls ceased to work correctly with ALP, Microsoft HTML help and the other custom protocol based environments. Therefore we strongly recommend you use the above technique even if in some next version Macromedia controls are fixed - there is no guarantee a future version will continue to work correctly.

To avoid such problems we are going to add to ALP a simple HTTP server capabilities as alternative way to use ALP. Yes this will solve such problems automatically but it will need TCP/IP support installed on the machines where the application works. So if you target machines which may lack of TCP/IP installation (such as the oldest Windows versions) you will still need to pay attention to this issue.