|A simplified diagram of the compilation process is shown on the picture
on the left. It shows what ASPC does in a typical case of ASP file processing. The other
preprocessing options supported are similar or exclude some of the phases shown here. This
page will assume no Compile Time scripts are used.
ASPC is a script host (as like ASP or
WSH). It uses a set of ActiveX controls build especially for the case and some universal
ones. IDE (Integrated Development Environment) is responsible to connect all them and pass
the control to a driving script which controls the process. In other words the harder work
is done by COM components (written in C++) and they are controlled by a script. Driving
script is in aspc.js file which must present in the ASPCIDE.EXE directory.
Thus clicking the button "build" you are invoking a script host which loads the
files you specified and applies different kind of filters over them in order to implement
the process shown.
Lets trace the processing step by step, of course excluding any details which will make
this page too long. Think for one file from the file listed in the project.
- Driving script (DS) loads the ASP file.
- DS passes the file to the parser component initialized with the ASP file rules.
- DS obtains as result simple syntax tree (not shown on the picture) and
immediately saves it to a file (in ASP to VB case it is a temporary file). The file is
plain VBScript in which for example all the <% %> tags are replaced with Response.Write
statements. In other words this file will run under IIS if one <% is placed on the
first line and one %> on the last (Note that ASPC has a processing option that does
it - ASPToASPPlain - without continuing with the next steps).
- Now DS passes the generated file to the VBScript structure analyzer/parser. It is a
parser component initialized with the VBScript program structure rules. It is responsible
to generate a Code syntax tree. This tree contains a
tree - collections of objects and other collections. In it all the parts of the code are
classified and for example every Statement is placed as sub item of the containing
Sub/Function and so on.
- DS reviews the tree and builds corresponding internal objects intended to
encapsulate every part of the script. All the arguments from the routines argument lists
are parsed and recorded in array attached to the routine enveloping object and all the
local variables too. The same is done with the VBS classes (in any) and their members.
Thus after this step DS has a full description of the code which can be searched.
- After finishing the above steps for all the files in the project DS has all
the code from all the files represented in the tree. And continues with the generation
phase. It generates the loader files and begins the
generation of the VB class files.
- During this step DS inspects every statement in every routine and generates its
equivalent statement for VB language. The most important task in this phase is the symbol linking. DS inspects every identifier in
the statement and searches for its definition/declaration. Also if a New operator
is found DS generates additional statement(s) needed to initialize the object correctly.
For more details on this phase see symbol linking.
- Finally DS generates a VB project file which describes all the class files and
additional project parameters. Depending on your configuration VB can be automatically
invoked to compile it.
As you may already suppose this scheme can be used to generate not only VB projects. We
will extend it and add new preprocessing options in future.
The process described above contains additional details, but these are the key steps in
it. ASPC project files keep information about the driving script used. Thus in
theory it can be replaced by another which does something different. In current version
all the supported preprocessing options have common parts thus we use only one script but
this will change in future.