What is ALP?

newObjects Active Local Pages (ALP) is an application development kit. With ALP the developers can build wide range of applications in almost all areas covered by the traditional RAD (Rapid Application Development) development tools such as Visual Basic, Delphi and many others. Still there are substantial differences in the way the applications are designed in ALP and in a typical RAD environment. In ALP the applications compose their user interface using WEB techniques - i.e. the developer designs HTML/DHTML pages and writes code that handles/manipulates them. However this does not mean that ALP is a WEB server - it just implements the user interface and user interaction methods known from the WEB development world, but directly without any network server components between the user and the application. Thus the ALP applications can be designed for almost all the purposes typical for non-WEB applications. There is no need to be concerned about firewalls or other problems that may be a problem for a WEB server application - ALP just resembles WEB server but it isn't.

Some of the obvious benefits are the ability to use well-known WEB techniques to build the application, easy to build complex user interface implemented in HTML which is familiar to the user and can be build with wide variety of tools - from a simple text editor like notepad to visual HTML editors like FrontPage. Aside of the employment of programming skills from the WEB development world in desktop programming environment the ALP applications are almost always ready to run on Microsoft IIS WEB server without changes as long as their functionality makes sense through the WEB (i.e. if the application will be useful as online application). All the ALP specific features can be ported the the WEB server machine by installing the ALP run-time library on it..

The ALP application structure can be illustrated briefly by this scheme:

All the operations are performed in a single application that runs on the PC - the ALP consumer application - an application able to load an use the ALP engine. Thus ALP works in the consumer's process memory. The consumer is most often Microsoft Internet Explorer or the ALPFrame browser (part of the Active Local Pages product), but other applications that can use asynchronous pluggable protocols can be ALP consumers as well. Most interesting for the developers are Internet Explorer and ALPFrame. The ALP applications are loaded into the consumer (we will refer to it also as viewer or browser) by using an ALP URL. For example and URL:

alp://C:/Somedirectory/somefile.asp

placed in the address bar of MS Internet Explorer will execute the pointed ASP file (if it exists of course) and display the HTML content generated by it. If this HTML contains links or a form user will be able to click a link or submit a form and thus invoke this or another file with the parameters entered into the form or contained in the link's HREF data. Although this very similar to WEB browsing it is not - everything is done by the browser and the ALP engine loaded in it (it is automatically loaded when an ALP URL is first invoked). 

If this can be done in Internet Explorer (IE) why use ALPFrame? ALPFRame is in fact a WEB browser based on Internet Explorer core, but designed in a bit different way. For example in IE you have standard IE menus, toolbars and other tools and only the work area of the browser is controlled by the HTML you show there. In contrast almost all the visual elements of ALPFrame are controlled by the HTML shown in it. Thus the DHTML content shown in it has access to all the DHTML objects available in IE, but it also has access to more features through the window.external property. Through it the DHTML scripts can access ALPFrame visual features directly and compose window and context menus dynamically or change the ALPFRame window appearance. Thus by using ALPFrame the developer is able to overcome some limitations of the DHTML object model and add additional elements to the user interface that will make the application behavior and appearance much like any other desktop application. If you are concerned about the portability of such a decision - remember ALPFrame ships with ALP thus it will be always available for your ALP application. What will happen if you want to port such an application (that uses ALPFrame features) on a WEB server? First of all ALPFrame can be used as a browser for it. To simplify such solutions ALPFRame registers a helper protocol entry that allows you use URL like this:

alpframe://http://server/dir/page.asp

to invoke any URL in ALPFrame browser - the alpframe:// invokes ALPFrame with the rest of the URL. Still, this means that the visitors should have ALPFrame in order to view the application correctly. This makes this technique good for known audience such as corporate environments, private WEB sites where only registered users may enter and so on. For WEB sites dedicated to the public you should specify that the user must download ALP to see the WEB site with all the features enabled (much like the WEB sites telling the visitor "please download this browser ..."). 

ALPFrame has also some other features that make it perfect for ALP applications and some other scenarios. First it supports special autorun mode in which ALPFrame constructs at run time virtual COM environment and allows an ALP application run without installation (Note that this requires special configuration - described in this documentation). Although most people associate autorun with CD autoruns it is much more. For example the fact that the application runs without installation means that it will not need to register components with the system in order to use them. Thus such an application does not need permission to write to the system registry and can be executed in any user account and from any media - even guest account and even from a flash memory. Thus ALP gives you ability to design applications that the user will carry on a flash memory disk/card or other similar media and run them on any computer at hand, do some work, remove the flash memory and move somewhere else. The user will not need special permission - any account will do.

Another feature of ALPFrame is the browsing restriction. This is especially useful in normal scenarios (when ALP is installed - not autorun) - you install one copy of ALP, but you can create different ALPFrame configurations that will allow the user access from the ALPFrame opened from that configuration only the specified applications and WEB sites. This is very handy in many corporate environments where the administrators are concerned about the security and especially by risks based on user misleading - for example phishing sites that may cause the user send internal information to external site. This feature is available not only to the ALP applications but also to the WEB sites and can be used in any combination as needed - ALP and intranet applications, ALP and WEB sites and so on. The administrators can create special links and force the employees use them to access ALP an Intranet sites and thus avoid any potential security problem. Note that ALP has more protection features and this is just an additional option.  

The primary development technique for ALP is Active Server Pages compatible pages. The application is written in VBscript or JScript and DHTML. However ALP supports also modular architecture and allows additional modules to be built to support other technologies. ALP always ships with ASP and CGI modules. The CGI support allows foreign technologies such as PHP or Perl scripts to be executed just like the ASP pages.

The ALP's ASP module is almost fully compatible with the classic ASP on Microsoft IIS with exception of support for cookies and a few other minor features. This gives the ASP applications cross-compatibility in the both directions - from IIS to ALP and from ALP to IIS. As we mentioned above the specific features supplied by the ALP run-time library can be ported to an IIS machine and the developer does not need to be concerned about their usage if compatibility with IIS is required by the project. Here is the place to remind the developers who meet ALP for the first time to take care to review each feature if they aim at IIS compatibility - in most cases ALP allows more relaxed syntax and more ways to do some things. For example ALP accepts in Server.CreateObject not only ProgID but also ClassID. Thus the developer should stick to the IIS supported syntax wherever ALP offers more relaxed rules in order to avoid need to pass through the application code and correct some lines when porting to IIS. 

If you have experience in the WEB development area you just need to get used of the idea that ALP allows you build (or port existing) applications for stand-alone machines and devices using the same techniques. If you are primarily a desktop applications developer you can consider this short comparison between ALP and a traditional RAD (Rapid Application Development) tools such as VB, Delphi and so on:

RAD environments: Usually form based. The developer designs a form, places controls and other visual elements, handles events from some of them and alters the state of others in the process.
ALP: The form is designed as HTML. It may contain whatever elements HTML may contain such as images and formatted text and allows very flexible design where you can mix document oriented design and absolute positioning as needed. The processing is done as whole - the user clicks an element/link or fills a form and this submits state information to ALP which returns a new HTML (or the same HTML a little changed - this is what the developer defines) and it is displayed in the viewer.
ALP: If behavior similar to the event handling of events fired by form elements is needed in ALP the developer can still use DHTML programming to alter the visual presence and even do some substantial work in the currently viewed form without submitting it back to ALP.

RAD Envirnoments:  When a database is to be used the developer uses special controls that connect to tables, recordsets/queries. Then responding to user actions that spark events the developer implements code that alters or activates them. For many traditional operations this is very convenient, but if more flexible formatting and processing is needed it becomes partially an obstacle. There is no way to place application built this way on a WEB server and use it through the WEB, to do this the developer would need to completely rewrite the application, preserving only the database and some pieces of code - only those that do not involve interaction with the user interface directly.
ALP: ALP may not have special database visual controls, but it does not need them. A list of database results can be generated with a simple cycle, form elements can be filled with a record data with simple print outs during the HTML generation. The processing of the user input is a matter of simple collection enumeration/indexing. Both data display and data processing can be customized as needed with little effort without need to obey design limitations imposed by special database controls. The processing/updates occur in well-distinguished moments of time - when the page is submitted and it is easy and understandable how and when to deal with database transactions, consistency keeping related tasks and so on. The application can be put on a WEB server (Microsoft IIS or another WEB server that supports the used technology) most often without changes or even if there is need of some they are inflicted by the developer on purposes different from mere compatibility.

RAD Environments: When the application needs to perform networking operations for example (such as custom connections to remote servers through TCP/IP) a component is used. If it is not put in a separate thread the user interface gets stuck unless the developer is content in spending additional efforts to use component that supports asynchronous connection handling which are often incompatible with some OS versions.
ALP: The ALP run-time library offers the developer ability to run threads, but even if the developer implements the code in haste - using blocking TCP connections for instance, the application will not be stuck as whole. Only the frame (or the work area of the browser) will remain in waiting state while the user will be able to cancel the operation or even close the application gracefully. ALP run-time library has networking components (see NetStreams) and the developer has no need to look outside for such or be concerned with their OS compatibility. If a custom networking operations are needed they can be implemented with ALP own components (note: we mean here application specific networking functionality which is not related to the ALP operation - e.g. something the developer wants to implement in the application and not the base application's user interface - as we said above ALP resembles WEB server but there is no networking activity involved in the content serving process).

RAD Environments: Depending on the particular environment the developer may use language provided tools or components (provided with the environment or 3-d party) to access the system features, access files directly in text, binary or record based modes, access the system registry and so on.
ALP: The ALP run-time library contains almost everything you may need. The components in the library are easy to learn and use and can be used outside ALP (including almost any RAD environment) if their features are needed there. This allows the developer use the same tools in ALP and in other environments. This saves not only time, but also allows cross-application compatibility to be gained with little efforts where a component specific feature is used. 

The main programming technique in ALP is ASP (Active Server Pages compatible processor) which allows the developer choose between VBScript and JScript languages (also other Active Scripting languages can be used and the pages can be written by combining more than one language). The ALP run-time library is our standard ActiveX Pack1 Family of components which includes:

File access components (see Storages and Files). This set of components generalizes the file system access by abstracting it as access to streams and storages. This allows the components to be applied not only to files but also to other objects that behave in similar manner - network connections, OLE storages, in-memory streams and so on. Whatever features are available for files are also available for other file-like objects. This way the developer gains text, binary and record based access to every file-like object and not just files. No need to use FSO (FileSystemObject) and the other objects notorious with their availability and anti-virus related problems. In exchange for a little learning the developer gets a set of components with much wider area of applicability that opens unlimited opportunities.

Networking components (See NetStreams). This set allows the developer to lookup nodes, establish connections and then drive them through the SFStream object from the Storages and Files component set. Thus the NetStreams brings the networking to the application abstracting it as file-like object once the connection is made. The developer implements networking specific code only for the connection establishing phase and uses common stream (file-like) techniques to send/receive data.

Embedded database (See SQLite COM). This component provides the application with fully functional embedded SQL database engine which has no external dependencies! The databases are kept in a single file (all tables, triggers, views and indices are kept in one file which is easy to move/copy). If the developer needs ultimate compatibility and wants to avoid troubles with ADO/MS Access versions and availability he/she can use the embedded database and do all the database work with it.

Threading (See COMScriptThread). This component allows the developer run a script asynchronously not disturbing the functionality of the application's user interface. Any long lasting tasks can be performed in the background and the application can check their state when requested instead of blocking the user interface by waiting them to complete.

Composite components (See Composite components). Allow the developer construct new COM components in a script language and optionally pack them in a single file. In contrast to WSC (Windows Scripting Technology) the composite components can be used without registration with the system. I.e. the application can create such component on-the-fly from its definition file not disturbing the user with installation and thus requiring extended user rights on the local machine. If the composite object is implemented using objects from the run-time library only it becomes even self-dependent and can be easily deployed in other environments and other machines.

UDS - Universal Data Structures (See ConfigFile). UDS data is a bit similar to XML. It can be managed in the application's memory as object model exposed through nested collections and can be persisted in files, streams and registry. It can be transferred in cross-platform compatible manner between applications and machines across the network. If the XML components cause you headache with their versioning and organization (often inconvenient for application specific tasks) you can rely on UDS functionality which ships with your application and can be easily provided on other systems by installing there the run-time library. We are preparing for the near future even more easy to use UDS management set of components which can be used as alternative way to manage the same data, thus giving the developer ability to choose between built-in small footprint (ConfigFile) and bigger but more convenient set of components (when you read this it may be already available - see on our site).

Collections/Dictionary objects (see VarDictionary and UtilStringList). The script languages offer a range of functionality that concerns data kept in arrays. Still when the data must be shared with other applications or when the data structure becomes too complex for an array the developer looks for a component that will provide more flexibility. With VarDictionary the developer can construct not just plain collections with values addressed by name or index, but also nest them (by putting a collection as value in some places) and thus use tree like structures in memory. VarDictionary offers search functionality that allows the application lookup information in complex and deep tree structures contained in such objects.

More. In the run-time library there are also many other components that may be of use for the ALP applications. They include:
- Script hosting (see ScriptManager and ScriptAggregate);
- String utilities - powerful string formatting that extends the popular standard from the C-library printf function.
- Synchronization objects - allow the application that uses threads and/or needs more complex inter-page/thread/application synchronization to control the flow of the operations.
- Advanced COM - For those who need to do more with COM - provide suitable environment for 3-d party components, run object in a separate thread if it needs sometimes more time to execute a member etc.
- Type conversion - patches the language features if they are not available in the language itself.

And more ...

Thus a typical ALP application uses the selected scripting language(s) to implement its logic. The ALP supplied built-in objects (Request, Response, Server etc.) give it access to the basic I/O (interaction with the user). The pages create objects from the run-time library (using Server.CreateObject or <OBJECT RUNAT=SERVER ...> tags) whenever they need certain features and use them to perform their tasks. If the ALP run-time library is not enough, i.e. the developer needs features not found in it or wants to access/control external applications through automation - then the developer can use the same way to create any external object by passing its ProgID or ClassID.

Which 3-d party objects can be used from within an ALP application? All the well-known components - ADO, CDO, FSO, the Active Directory components and so on. Also, as ALP runs on the desktop it can be used to control/automate desktop applications - such as MS Excel, MS Word, MS Outlook and so on. Such a functionality is usually associated with VB/VBA applications or Windows Scripting Host, but with ALP it can be implemented in an ASP page or in a script running in a thread created by your page.

Thus ALP combines easy to design/control user interface with ultimate COM features access. Having the rich ALP run-time library packed with the application allows the developer choose any suitable way. For example:

When the application is intended for distribution to the retail market the developer uses preferably components from the ALP run-time library and external components that are compatible with most platforms and do not depend on non-standard system features. The resulting application is easy to install and can be even packed as autorun and started from a CD/DVD/Flash Memory without installation. An application based on ALP and its run-time library only will work even in a totally restricted guest account from a removable media!

On the other hand if the aim is integration with specific software running in your office/organization the application can use the COM objects offered by the software to directly control/query this software. Still the core of the application will remain portable an easy to deploy and the developer will be concerned only about the extranal software availability and configuration. For instance some of our clients use ALP to construct applications that can be used alone, but can also connect to the corporate SQLServer, MS Exchange server and other typical corporate applications when the computer (usually laptop) connects to the corporate network. When the application must be able to work both alone (with cached data for example) and also integrated with the organization's software ALP offers simple and portable way to do this. When it is even needed to host the same application on the WEB ALP is perhaps the only solution that will allow you do that without need to write almost everything again. 

Conclusion

While ALP with its primary ASP compatible programming interface offers own set of libraries, viewer and other tools - the developer is not restricted to them. The included libraries are well tested for cross Windows OS version compatibility and are especially designed to work without external dependencies and need of local machine configuration. The developer is still able to use any automation enabled COM object from outside and thus build applications that integrate/interact with other software, corporate systems and so on. It is true that many components from the ALP run-time library have functionality that overlaps with some popular components - an example:

Storages and Files (SF) component set (see SFMain) covers most of the functionality of the Scripting.FileSystemObject (FSO) from the Microsoft Scripting Run-time library. Nevertheless SF component set offers more features and is built so that the developer can use the same API-s for files and other file-like resources while FSO is not - for example through SFStream you work with files, memory streams, OLE files, TCP/UDP connections, IRDA connections while FSO provides access to files only. Furthermore SF is always available with ALP while FSO may not be available on the target system and would require additional efforts to redistribute and check for availability. Additionally SF components allow text, binary and record based access simultaneously while FSO offers text access only.

The situations is similar with many other components in ALP run-time library which means that using them the developer will need to learn how to use them, but effort will pay back with more features available to the application and more opportunities. So the developer may choose freely which components to use when it concerns functionality covered by both ALP run-time library and 3-d party components. Thus the developer can choose whichever is best for the particular purpose - when maximum portability is needed ALP run-time library is best, when integration with other software is the point the developer can use the external components. When porting existing application this allows the user avoid the need to rewrite huge amounts of code and resort to such a measure only if ALP run-time libraries will offer a substantial benefit not offered by the components used in the original application. 

Usually the COM based open environments are claimed non-applicable for autorun scenarios (such as running application directly from a CD with none or minimal installation, or downloading a package and just starting it by running an exe file in it). However ALP overcomes this and allows it with acceptable limitations (All the ALP supplied components are not affected by these limitations)! This opens some areas that are hard to reach even for many products built in C++ - such as running application in guest accounts (with absolutely no rights for installation of anything).

The system requirements of ALP and its run-time libraries and tools.

• ALP needs Microsoft Internet Explorer 4 or later to be installed on the system.
• It will run on Windows 95, Windows 98, Windows 98SE, Windows ME, Windows NT/2000/XP/2k3 and later versions without need of additional components
• On Windows Win95/NT4 it requires at least Internet Explorer 4 to be installed.

Note that ADO, MSDAC, FSO and other components typically used in ASP programming are not part of ALP itself - they are external components. They are popular and most often pre-installed on most Windows systems. However the developer who builds an application that employs them should check their requirements and availability in Microsoft documentation. If because of some reason their scope of availability and requirements is not suitable for the application the developer may resort to the ALP run-time library which supplies alternatives for all of them.

You can start learning Active Local Pages by going to the Getting started page.