How the Scripting Object Model Works

The files for the Scripting Object Model are contained in the _ScriptLibrary folder that Visual InterDev 6 inserts in your Web project when you create a project. (See Figure 4-2) You should never change anything in one of the _ScriptLibrary files or delete any of these files.

Microsoft is going to replace the JScript files that make up the SOM with a set of components written in C++ using the Active Template Library (ATL). The new Scripting Object Model components should provide faster execution, a more stable environment, and a true black-box architecture for the server. In the interim, you should treat the Scripting Object Model as a black box (that is, you should not be concerned about how it accomplishes its tasks).

Figure 4-2. The _ScriptLibrary folder contains the Scripting Object Model files.

ASP files execute in a linear manner as indicated by Figure 4-3. When a user visits an ASP file, the page starts executing at the first line of code and continues to execute sequentially top to bottom. Once the code in a page is executed, the HTML generated is sent to the browser via HTTP. The only changes to the linear flow of execution are governed by the logic in the page that might call procedures or redirect the flow of execution directly.

Figure 4-3. The ASP execution model is sequential from top to bottom.

DHTML pages, on the other hand, execute in an event-driven manner just as Visual Basic applications do. Figure 4-4 demonstrates how this can look when a page executes.

Figure 4-4. The DHTML execution model is event-driven.

In Figure 4-4, when a user clicks a hyperlink to this page, the onload event will execute when the page loads. The onclick event will not execute until the user clicks the command button. This execution model greatly simplifies the way you build Web applications and reduces the long-term maintenance costs of the applications. You as the developer can control what happens when particular parts of the page execute. This allows you to isolate your code and execute code discretely when certain actions (events) occur in a page.

The Document Object Model of the browser exposes the page as an object hierarchy. The script in the page can execute against the Document Object Model, automating features of the page and making it dynamic. DHTML pages are typically event driven, with code that is contained in event procedures within the page. Of course, you must be using a browser that supports DHTML, such as Microsoft Internet Explorer 4, to use the DHTML features.

The Scripting Object Model works with both DHTML and ASP files. It provides the framework to allow both ASP and DHTML Web pages to execute in an object-oriented manner. Figure 4-5 demonstrates how ASP files have an object model when using the SOM.

You can see the event model of ASP files in Figure 4-5. This new event model is particularly interesting as it allows you to script events for DTCs in either the client or server. Whenever you use the Scripting Object Model, at run-time an object is created for each DTC and the current page. These objects are the mechanism that you use to have access to the features of the page and its DTCs. More on this in a moment.

Figure 4-5. The Visual InterDev 6 Scripting Object Model provides ASP events.

The DTCs' event model is implemented by the Scripting Object Model at run time. This allows you to build events in client or server code. Usage of the new DTCs is covered in detail in Chapter 6. The server events for pages are provided by the PageObject DTC, which is the foundation for page type events and other support for treating pages as objects. Its close relationship to the Scripting Object Model is the reason for covering it in this chapter.