|As in the classic ASP special
COM objects can be created that are able to bind tightly with the ASP
engine. you can use whatever COM enabled development tool you
The special ASP objects are advised when created for the ASP
objects (Request, Response, etc.). Thus they are able to fetch, put
data directly to the ASP engine without help from the script on the
page that created them. In many cases this may simplify the project by
reducing the code needed because the objects are able to get what they
need on their own and the script in the ASP page will not need to
transfer values from the environment. It is obvious that this
technique is most useful for objects specific for aparticular project
and not for universal utility objects (except a few rare cases).
How this works:
In a regular ASP page whenever an object is created using the
Server.CreateObject or the <OBJECT RUNAT=SERVER ... > tag the
object is checked for two methods that can be implemented in it: OnStartPage
and OnEndPage. They are expected to be IDispatch methods
(also called automation methods). If they exist they are called -
the ObStartPage before the page processing begins and the OnEndPage
after the page finishes its work.
The prototypes are:
HRESULT OnStartPage(IDispatch* context);
The OnEndPage is not required - if the object has nothing to
un-initialize it can be skipped.
The context (ctx) variable passed to the OnStartPage contains an
ALPScriptingContext object which has these read-only properties: Application,
Session, Request, Response, Server. All they return the
corresponding ASP object. The returned value is of type Object
(VBScript), IDispatch* (C++).
Note that you should NOT use the types
ScriptingContext or Request, Response and the others known from the
classic ASP! ALP is not binary compatible with the classic ASP and
you must refer to the objects only through automation (IDispatch)
interface. In VB this even saves some writting -you do not
need to specify the type name - just use un-typed variable. In C++
you must use IDispatch::GetIDsOfNames and IDispatch::Invoke to call
the context's and the ASP objects' properties and methods. The
objects built after this fashion will be compatible with both
classic ASP and ALP and even with 3-d party ASP engines.
How to build ASP objects?
You have many options. We will point out how to proceed using
some of them.
VB: Create a standard ActiveX DLL project. Implement one
or more classes in it. In each class implement the OnStartPage and
if needed OnEndPage method. Preserve the received context variable
in the OnStartPage method for example:
Set SomeClassVariable = ctx
Then use ctx.Request, ctx.Server and so on whenever you need to
access the ASP objects directly from your class.
C++: The best way is ATL. Create an ActiveX DLL project
and implement the required methods. To simplify the IDispatch calls
to the context object you can use the DSIPCALLER C++ class supplied
with ALP (see in the SDK resources directory in the ALP
installation folder). If you are building explicitly for ALP you can
import the ALP type library and use the IALPScriptingContext
interface, but do not forget this will be ALP specific.
Composite objects written in script: The ALP run-time
library supports the so-called composite
objects. With them you can create COM object entirely in script.
This technique has a similar equivalent you may know - the Windows
Scripting Components from Microsoft. However the ALP composite
objects are dynamic and may run without installation (e.g. they can
be used in autoruns for example - not necessary to register them).
Also they can be created directly from their definition file which
makes this very useful if you do not want to install huge amount of
COM objects with a setup program (see the composite
objects part of this documentation for information on how to
build components in script) . To support this ALP supports a
specific setting for the ScriptGen (ALP's ASP engine module) content
generator - ExtendedCreateObject. If available and set to non-zero
integer value it causes ALP to try to create objects in all the
possible ways: CLSID, ProgID, composite object definition file,
directly from DLL by CLSID. You will need to set it if you want to
be able to create composite objects directly from
Server.CreateObject or <OBJECT> tag not registering them as
regular COM objects. This extension allows you to use in the
CreateObject and the <OBJECT> tags parameters like
Server.MapPath them of course). This way they will be initialized
and asked for OnStartPage event if they support it. Without this
extension enabled you can specify only ProgID or ClassID in the
create object routines/tags. See also the ScriptGen
configuration and the Pack1Creator.CreateObject
(the parameters described there can be used directly in
Server.CreateObject if the extension is enabled, the default flags