After four years of .NET, n-tier and service-oriented architectures, object-oriented programming and design patterns, I have been assigned a small… “Classic ASP” project, for Reuters. Yeah, you got it, the good’ol plain vanilla ASP, VBScript and so on.
The good news is that my technical contact at Reuters is Adam, a good friend and ex-boss of mine (yeah you can become a good friend of your boss… after the company they’ve worked in together has gone bankrupt :) )
Dusting out my (by know fairly limited and mostly forgotten) ASP knowledge, the first thing I found out is that it is increasingly difficult to find information on the web about ASP; the trick was to Google like this: “Session ASP -.NET”, that is, specifying that I do not want .NET-related stuff in my results list…
Once I found this trick, life was easier. The messy part came right after, when I (re-)discovered that “Classic ASP”… is the Land of the Forbidden Maneuver. What I mean is this: ASP development gets harder and longer, not because of the complexity of the business rules or something like that, but just because of (among others) these Major Commandments:
- Thou shalt not store a VBScript class object in the ASP Session unless it is a VBScript Array or a Scripting.Dictionary object: “A somewhat more technical problem can arise when using VBScript classes on the ASP Web server. The ASP server is multithreaded and assigns a different thread to each page request (and hence each script engine). But VBScript class instances are apartment-threaded objects, which means that they must run on the thread that created them. Therefore, attempts to use one instance of a VBScript class on two different pages via storage in Session or Application scope are doubly doomed to failure.”
- Thou shalt not create a disconnected ADO Recordset using JScript unless you mix VBScript and JScript in the same page (which can be tricky, see the next commandment for details)
- Thou shalt not mix freely VBScript and JScript on the same page, even if they say you can; compiler problems may arise and the behavior of your page becomes random…
- Thou shalt not use “Server.GetLastError()” freely; it can be only called from a page that has been set-up as the 500-100 error handler in IIS (which is a problem, if, like me, you don’t have access to the IIS MMC of your client’s server… and your client either - too long to explain…)
- Thou shalt not inherit VBScript classes; code reuse is done through server-side includes: “VBScript 5.0 is not strictly an object-oriented language like C++ or Java. There is no notion of polymorphism or inheritance in VBScript 5.0. Though VBScript classes allow you to define your own objects, you cannot define an object hierarchy where, say, a Terrier class is a subclass of Dog, which is a subclass of Mammal. VBScript classes are merely a way to group data and the operations on the data together to improve encapsulation.”
- Thou shalt not use any “Return” keyword to return a value from a Function; thou must use the (awkward) way of using the function name for that (what if I want to change the name of the Function afterwards, introducing a bug?); if you forget to do this, you will not get a compilation error, not even a runtime error; just a “Nothing” as a return value, and some new white hair for free.
- Thou shalt not use parenthesis when calling a Sub with more than 2 parameters (whoever came up with this idea in Microsoft should be sent to Mars to change the batteries of Spirit and Opportunity, without a space suit)
- Thou shalt define Class properties using the “Property Get”, “Property Let” and “Property Set” (?) statements; the meaning of the first is quite simple, the difference between the second and third one… is arcane.
- Thou shalt always use “Set” when filling up a variable that contains… anything that is slightly bigger than a String: ADO Recordsets and Connections, COM objects of any kind, instances of your own classes… you name it. If you don’t, you will get a meaningless runtime error; not even a compile-time error, a runtime one, and God bless your soul, kid.
Anyway, you get the idea.
A last commandment of the Land of the Forbidden Maneuver, just for our salvation:
- Thou shalt not forget to scan the open-source world to finish in time your Microsoft-related project!
Update 2005-09-25: I forgot to add this one:
- Thou shalt not use the “Multiple Recordsets” feature of the ADODB.Recordset class if you use disconnected recordsets…