We mentioned earlier, that "we make calls to one or several of the ASP intrinsic objects to create the dynamic element of an active server page". These objects are immediately accessible to the ASP developer and neatly cover all the key aspects of creating dynamic and interactive pages. Together, the five intrinsics and their parent object form the hierarchy that is the ASP Object Model, which looks something like this:
Each of the objects has a set of collections, methods, properties and events which provide them with all their functionality. The following chapters will take you through the calls and syntax of the five objects, but for now we'll have a brief look at how the objects divide up their work.
It's a bit of a cheat to include the scripting context object at the root of the ASP object model. Even though this is its rightful place, you'll never have to reference it directly because it simply represents the scope under which any scripting in ASP runs. Whenever a block of ASP code is run, ScriptingContext is created automatically, making the ASP intrinsics available to the scripting host along with the scripting objects. Similarly, when the scripting host finishes parsing an ASP page, it destroys the instance of ScriptingContext automatically.
In Visual Basic you can create an instance of the ScriptingContext object to get access to the ASP object model – this is what Visual Basic's new WebClass feature does.
One of the main reasons that first scripting languages and then ASP were developed was that by themselves, HTML pages did not 'respond' to the client. They were static. The advent of scripting languages brought us the ability to determine what was going on within a page and react to that but these 'interactions' were limited to a developer second-guessing a user's actions and pre-programming a reaction. Only with ASP did the technology come into being that allowed a client's action (his response) to be 'seen' by the server and dealt with by the server. For an ASP developer, a website 'listens' to the client browser with the Request object and then answers using the Response object.
As time has gone by, we have seen the transformation of static web content into fully competent web-based applications. We can now check our bank account, buy a computer, or hire a llama over the web – and most of the web applications (or weblications, if you prefer hideous contractions) online today are written and developed just as they would be if they were to be packaged in a box. ASP pages provide the user interface while COM components encapsulate the necessary business logic and let us access databases where our business information is stored. The only difference between developing applications for commercial distribution and web applications is the question of state.
The protocol over which web applications are run – HTTP – is stateless. It cannot remember from one page request to the next who you are, what you are doing or even what page you last looked at. Nor can it retain, for example, what items you're currently buying from amazon.com or CDNow. This is where the Application and Session objects come in, providing the virtual memory for a web application to run correctly and retain state.
Finally, we have the Server object, the least populated but arguably most useful object of them all. This contains four miscellaneous methods that the server performs, the most utilized of which is CreateObject – which allows us to create an instance of an ASP component.
