Using the compiled modules.

What replaces the compiled ASP pages and other scripts? 

This chapter is about the results of the processing options concerning ASP or other VBScript files. If you are meeting with ASPC for the first time it is recommended to take a look at the available processing options first.

ASPC processes series of script files or/and ASP pages. In most cases these files are part of some project/application/site. We decided to make the output easy for deployment - manual or automatic. Thus ASPC output can be separated in two categories:

1. Files related to the DLL creation
2. Files intended to replace the source files. 

The first category - VB class modules and other files are stored in one directory and they are subject of the developer's interest only in rear situations such as some bug tracing tasks. Thus they they are stored in manner more convenient to the Microsoft Visual Basic compiler and in second place for human reading.

The second category - replacement files are called in this documentation "loader" files. Their purpose is replacement of the input/original files in the WEB site or another scripting application by using the compiled COM class generated over the first category of files. These files are subject of direct interest for the developers and also the developer may need to edit some of them, make their copies and so on - depending on the application purpose and structure.

To simplify their usage and keep the original application structure ASPC stores them in a directory structure equal to the original structure found under the source folder. This is the reason for the settings you need to supply in the project settings. You supply there source and output directory - ASPC processes the files you specify from the subtree under the source folder and outputs the loader files for them under the output folder in the same relative locations. Example:

If your source folder is C:\src and one of the processed files is C:\src\dir1\dir2\one.asp and the output directory is C:\out then the loader file for the processed ASP page will be C:\out\dir1\dir2\one.asp . 

Of course if you have another directories and files in the source tree, but they are not configured with the project they will not be processed and folders for them will not be created. Thus you have the choice to configure everything in the project or combine it with a little manual work as appropriate. 

Loader files are simple script files stored in the same format as their sources - e.g. if ASP file is processed - the loader will be an ASP file, if plain .vbs file is processed - plain .vbs loader file will be generated. Their job is to load and initialize the appropriate component from the DLL and invoke it. One example file:

<%
Dim proc
Set proc = Server.CreateObject("ASPHello.cls2HelloWorld_VBScript_asp")
Set proc.Application = Application
Set proc.Request = Request
Set proc.Response = Response
Set proc.Server = Server
Set proc.Session = Session
proc.ASPCExecuteClass
%> 

As you can see the loader creates an object, sets its properties and finally calls the predefined Sub created by the compiler. This Sub implements the page behavior. Thus the loader file invokes the compiled implementation of your page passing the environment objects (ASP objects in this example) to it - by setting the appropriate properties of the object. You are able to move this file to any location where the original page will be appropriate and functional. Of course the only additional requirement is the DLL registration on the machine.

The samples supplied with the compiler show non-standard usage. In such case loader file may need some changes or can be used as an example how to add the compiled page functionality to another non-compiled page. Special interest for many developers will be ability to reuse one page in different sites/applications. By using the Discard directive some settings can be set from outside - which means from the loader file. Usually page reuse is done by copying the page to the other application and some minimal changes in the code are enough to adopt it. This is not the best way for the compiled pages and causes too many similar components to be registered on the same system. Leaving some of the global variable assignments for the outside world is in fact conversion to public properties of the compiled class. Thus the mentioned technique allows the developer to make different copies of the loader files. Adding manually a few lines in these files configures the page for the requirements of the particular a-application. This is mostly subject of the application planning - see the example "configurable" and its description in the main Readme.htm file in the samples directory.