|
Send questions to support@newobejcts.com
mail address. See also the ALP discussion
forums.
This article contains several topics related to the compatibility of ALP with
certain popular WEB techniques/technologies.
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!
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.
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.
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:
<object
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0"
width="400" height="300">
<param name="movie" value="movie.swf">
<param name="quality" value="high">
<embed src="movie.swf"
quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash"
width="400" height="300"></embed></object>
Should be changed to:
<object
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0"
width="400" height="300">
<param name="movie" value="<%= Server.MapPath("movie.swf") %>">
<param name="quality" value="high">
<embed src="<%= Server.MapPath("movie.swf") %>"
quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash"
width="400" height="300"></embed></object>
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:
<object
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0"
width="400" height="300">
<param name="movie" value="<%= CreateURL("movie.swf") %>">
<param name="quality" value="high">
<embed src="<%= CreateURL("movie.swf") %>"
quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash"
width="400" height="300"></embed></object>
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.
|
