Adopting ASP/VBS applications
This chapter is intended to give you some general ideas on how to use the ASPC better
when compiling ASP and other VBScript applications to COM DLL(s).
First you should be aware of the fact that the compiled DLL cannot be changed at any
time as the textual ASP page or another script. Thus you will benefit of every successful
attempt to foresee the page/script usage in location/place different from the current one
(if possible). Thinking for the compiled pages or scripts as for a libraries which will
fit in several applications may bring some good ideas how to improve them and make them
less dependent on data or circumstances specific for the current environment only. This
process depends on you but in certain points you will need some help from the ASP
Compiler. Thus we add some initial features and we will add more upon the developers
requirements.
Configuration
One of the most common features is ability to configure the compiled class instead of
recompiling it for every single project. This feature is mentioned in other places in this
documentation and is also demonstrated with a simple example (see configurable example in
ASP samples). In short this is done using the Discard
directive that allows certain statements to be exluded. Usually these are intended to set
some hard-coded parameters in the source ASP page or script.
Why discard them? In most cases these statements set values to some of the global
variables, used later to determine behavior or find required resources. Compiling the
page/script makes impossible to change them later. This is not appropriate if the meaning
of these values is for example path to an external resource. If the page/script will run
correctly with every resource similar to the hard-coded one then why not leave this path
in some kind of configuration or property? This is the reason to discard these statements
- discarding them you need to add 1-2 lines in the loader
file to pass to the compiled code the required parameters before its execution.
An example:
Dim Param
'#! Discard
Param = "C:\file.txt"
Suppose the Param is used to determine a text file used by the script code in
the page. Than you may need to change this file sometimes or make several copies of the
script using a file with the same format but with different content. Then the discard
directive will leave the global variable Param unset and you will need to set its value
from the outside - in the loader file:
' Loader file code - omitted for brevity
proc.Param = "C:\anotherfile.txt"
proc.ASPCExecuteClass
See more details and samples on the Directives page and
the ASPC samples.
One specific example is provided:
1. Example3: Configurable - Implements a page
that needs some data to be set from the loader page before the execution of the main code.
See the sample description - without editing the loader file you will receive errors
caused by the missing data required by the compiled page. |
Library or packing functionality in a reusable component
Another interesting usage are the private libraries. Usually they are kept in include
files or sometimes placed in every file again and again. The libraries may contain set of
multipurpose routines or/and VBScript classes. With the evolution of such library the size
of the include files grows and thus the time required for a particular page processing
increases.
Well, ASPC will remove this problem automatically but why not pack these include files
as a separate component(s) and use them instead? There are several different ways to
achieve the target. Choice is entirely yours and we will explain the easiest way only:
Empty page
This is the easiest way - to create a minimal ASP page (without any output in it) which
includes the desired library include files. the intention of that page will be
initialization (if any is required). Compiling it (or a set of such page-includes
combinations) a DLL will give you a DLL which contains the library routines as public Subs
and Functions. To use it you will need to place the code from the generated loader file
into the file which will use the library, probably rename the variable holding the object
with something more descriptive and call its members in place of the calls to the
functions and subs originally found in the include files. Also any variables declared
globally will be accessible as properties.
If the library contains only Functions and Subs this will be enough and possible
adjustments will be caused by the specific language requirements - such as public arrays
which are not allowed and so on. But if you have some VBScript classes in your libraries
you will need to use some of the ASPC directives in order to make them accessible for the
outer code.See the Public directive and Createble directive (The second one is not recommended
for developers with no experience with COM programming).
The purpose of the above directives is to make the objects of these classes accessible
for the script using the library. But this will not make them creatable as like the other
VBScript classes defined in the script! Thus you will need to make some additions to your
library - responsible for their creation. See the Directives
for an example how to do so. If you are still confused about the need of these additions
remember the major facts about the compiled classes - they are COM classes implemented in
a DLL and your script accesses them as COM objects. They cannot be created as a script
specific objects - they are accessed and created in the manner typical for the other COM
objects you are using in your application. But simple usage of CreateObject will not be
enough because in nearly all the cases depend on some global variables, or another objects
and thus they need initialization. This is the reason to implement a creator
function which creates new object of a certain class and ensures it has access to all the
required data.
Two examples are provided:
1. Example7: Simple library - illustrates the
above method
2. Example5: Users component - Implements
class which is used in several pages.
Building COM components from plain scripts
As alternative to the Windows Script Components you can use ASPC to build your own
ActiveX components. To do so you can use plain VBScript files and some of the ASPC
directives.
What are the requirements:
- First of all these scripts must not use any global namespaces! You should delete
all the namespaces in the project settings dialog.
This will invoke errors if the script depends on some global namespaces and will help you
to deal with them.
- It is recommended to not use global variables if possible. If they are required
every object will need a call to a certain member before any other calls. This call should
check/initialize the content of these variables. In this case you must supply this
information with the component.
- The ideal solution will be enclosing all the code in VBScript classes and
make them Creatable or Public as appropriate.
- If VBScript classes are used they should not depend on global variables or
routines (except those declared with DLLGlobal
directive).
If you need a complex cooperation between several objects you can still make them
dependent on global routines or variables, but you will need to supply creation routines
(global ones) for them. The compiler is able to reduce the required work, but such
scenarios require average experience in COM programming
Two very simple examples are included with ASPC:
1. Example8: Simple component example - which
implements a simple class from a VBScript file. Note it contains only one class!
2. Example9: Simple components 2 example -
which implements two classes as VBScript classes and using directives makes them
accessible from outside.
Every example has a description - use the samples shortcut from the program ASPC's
program group in the start menu to reach them.
|
