ALP 1.5 combines the latest additions to ALP engine and its run-time library
(A rich set of COM classes you can use). While ALP itself has some minor features
added most new features are in the run-time library. There is a list of the major modules
included with ALP 1.5:
You may know some of the new modules already if you are using ActiveX Pack1 with which some of them were already published. Anyway, some
new features were added recently and you may find useful the short comments about them later in this page.
This section will be appended frequently the following month until the official version is released. If you cannot find what you need here feel free to e-mail us.
Before reading further, keep in mind that all those components are built
with IIS and ALP in mind. They are optimized for IIS/PWS servers and can be
used for non-ALP based ASP development. Therefore most comments below are not
ALP specific and some are applicable only for server usage (such as
performance capabilities).
SQLite3 COM. SQLite3 is mature database engine supporting SQL features one would not expect from an embedded database. It has evolved in a bit different
direction than the database servers, our derivate has gone even furhter. The first things first, SQLite3 COM supports query parameters
in various manners, for instance you can write:
Set results = db.VExecute("SELECT * FROM T WHERE FIELDA=$a AND FIELDB=$b",1,0,FieldAParam,
FieldBParam)
Or you can use collections and pass them directly as parameter sets like this:
Set coll = Server.CreateObject("newObjects.utilctls.VarDictionary")
coll("a") = "Peter"
coll("b") = 30
Set results = db.CExecute("SELECT * FROM T WHERE FIELDA=$a AND FIELDB=$b",
coll)
The real trick is to use session parameters. You can set some parameters
for the duration of the session:
db.Parameters("USERID") = Session("CURRENT_USER_ID") '
Assume you have recorded it in the session during the login.
And then use them in queries, views and triggers. For instance you can create
view that takes into account the current user and returns relevant results.
The effect is that the application code becomes simpler (it works with the
view and does not need to take care about passing boring parameters like the
current user). For example:
CREATE VIEW VITEMS AS SELECT * FROM ITEMS WHERE OWNER_ID=Parameter('USERID')
If you want to cry "this is nice!" you probably also would ask why
is this possible with SQLite and not possible with database servers? SQLite
works in the thread of your ASP page, by opening a session (db.Open) you
create a new database engine's instance dedicated to your particular request -
it is yours and you can do with it whatever you want. On the contrary the
database servers are used through connectors (in ASP this would be ADO/OLEDB)
which consume precious resources - network connections, cache and to mitigate
the problem they maintain a connections pool where the same database session
is reused sometimes even by different users let alone different pages
(depending on the application). There is no way to create a session parameters
feature in such a scenarios without added costs measured in additional network
transfer, complicated session synchronization and so on which will render the
feature useless. SQLite has advantage here - it needs negligible time to init
a new instance of the entire database engine (times less than the time needed
to establish connection to a database server) which makes it viable to make
on-the-fly session configurations that would simplify the application/database
interoperation. In fact working with SQLite3 database is as fast as accessing
a local file - the rest is up to you: create good database schema, plan good
indices, create views and triggers that will make your work easier and the
code simpler in the end this will gain you more performance than any
complicated database access architecture would. Is there a downside to this?
Yes everything has its price - this technique is for embedded databases which
means you cannot scale the application to several servers. So, the verdict is
you can gain more from a single server this way, but you sacrifice the scalability.
For ALP, of course, this is not an issue - it works not only on one machine,
but for a single user, but if you are building application for the WEB make
your estimations first - if you plan to go for more than a few hundred
thousands hits per day with a complicated database you should look beyond
SQLite. If not, you will save yourself a lot of work and a lot of resources on
the server (the memory consumption is many times lower than in ASP.NET/MSSQL
for example) and the server will be able to serve much more visitors than it
could if a heavier database and WEB technology is used. To bring some order
lets define what an average database schema is: Something with 30-100 tables
where single page performs about 20-30 queries where about 10 of them join 3-4
tables (usually outer joins) and 2-3 conditions in the WHERE clause. From
these most are read (select) queries and only 2-3 per average page are assumed
to be write queries (insert/update). Some simple optimization techniques can easily
enable such an ASP/SQLite3 application to serve up to 2 million requests per
day on a minimal server with under 2GHz single core processor.
Read more on the SQLite3 COM WEB page
WebImage. Everybody needs something for image processing from time
to time. This component offers the ASP pages means to change image sizes,
apply a number of simple effects/adjustments, convert from/to different image
formats (jpeg, gif, png, bitmap and so on). The component comes in two flavors
- server side (for usage in ASP pages) and client side (for usage with client
side javascript). While the second version requires it to be installed on the
client's machine it offers some interesting advantages - such as scanner
support (through WIA which is the Windows standard today for scanner access.
TWAIN is not supported because the drivers or often unstable and this is not
suitable for an ActiveX working in the browser). While using the client
version in public applications may be unwise, because of the many different
browsers today it is a good choice for intranet applications. In public
applications one usually prefers the server side - where the server version
comes in handy.
HashCryptStreams. Symmetric/asymmetric cryptography and
hashing algorithms bundled together in a form naturally fitting the abstract
stream features found in ActiveX Pack1. They can be used both directly (to
hash/crypt/decrypt blocks of data) or over streams allowing the
encryption/hashing to occur as part of file read/write operation, network
transfer and so on. If you are unfamiliar with ActiveX Pack1 streams (SFStream
for instance) and their use with files and network connections you may find a
shortcut in using the cryptography components over data you fed into their
methods as simple parameter, but the streams may save a lot of work if you
plan to create library routines/classes.
ActiveX Pack1 core. (Its WEB page is here).
This is the core for many components and contains over 30 classes covering
features like file access, abstract streams, binary/text/record based work
with streams and consequently files, universal collections like VarDictionary
(capable of behaving as list, stack, queue, dictionary), script manipulators
allowing you to load and run VBScript/Javascript code directly or asynchronously
in a separate thread, string formatting utilities and many more. Most other
modules use ActiveX Pack1 core to some extent which allows you to base your
knowledge about ALP and its run-time library on common base of a few central
classes and read about the rest only when needed.
