WebRef Update: Featured Article: SOM - Your New Baby

SOM - Your New Baby

For a Web developer, discovering the scripting object model, or SOM, is a lot like having a brand new baby dropped in your lap - it's new, beautiful, and exciting, but unfortunately, it doesn't come with any directions. So you, the doting Web developer, strive to learn how to work with this wonderful addition through trial-and-error, and wind up with a lot of sleepless nights! Where is Dr. Spock's guide for making the SOM a mature member of your family of development technologies? I can at least tell you that the first chapter is right here. My goal in this article is to make you familiar with the SOM, and in the process show you the incredible capabilities it can add to your Web projects. I'll also be sure pass along a couple of tips I've discovered - while chugging coffee and listening to the late, late show in the background.

The SOM originally shipped with little fanfare as a part of Visual InterDev 6.0 from Microsoft. Users of other tools generally haven't heard of it or seen it. Even VI users typically work with the SOM indirectly, by using VI's design time controls (DTCs). In reality, the SOM has a lot to offer all Web developers, and its usefulness goes far beyond the role of providing the underlying functionality for VI's DTCs.

First, a quick note - if you haven't run into DTCs, they are simply regular-old ActiveX controls with a special interface for generating text. The text they generate is typically source code that would otherwise be challenging (and tedious, given the amount of it) for you to add yourself. They can be used in development tools other than VI, though the DTCs that ship with VI are designed specifically for use in VI. For example, in Visual Interdev, it's easy to drop a Recordset DTC on a Web page and then add database connection and record source information, such as a connection string and a SQL statement or table name.

So, you ask, what's in it for me (other than the pure entertainment value, or course)? Well, you could add a textbox DTC and then bind the control to the Recordset DTC. The two would work in tandem to insure that the textbox is populated with the correct information from the recordset and that the recordset is updated when a user changes the content of the textbox. It's saving those hours of otherwise hand-coding the stuff that's in it for you! There's a corresponding DTC for every standard HTML control, and they can be placed on either ASP pages for cross-browser functionality, or on DHTML pages for IE 4.0+-only applications. Tying this all back to the SOM, the text generated by the DTCs consists of server-side and client-side script blocks from which calls to SOM routines are made. In the case of cross-browser pages, those routines build and manage the objects using standard JavaScript and HTML. Pretty neat!

That's a glimpse of the Rapid Application Development, or RAD, side of the SOM and of DTCs. The inspiration for the SOM goes further, and was none other than the rich, event-driven paradigm of client Web-pages provided by the document object model (DOM) and Dynamic HTML (DHTML). If you think about it for a second, how many events are intrinsic to the ASP environment? I can think of four: the OnStart and OnEnd events of the Session and Application objects. Wouldn't it be nice to have a rich set of events just as you do in your client pages? Another brainteaser: how do you control the flow of code execution in your ASP pages? The answer: you don't, except for when you explicitly call functions and subs, or include inline server code. Microsoft steadfastly insists in numerous documents that ASP developers must not rely any particular order of execution of ASP code, because they don't guarantee it! Wouldn't it be nice if you could? And even better if you could make a distinction between the first time a user hits your ASP page and all subsequent hits to the same page by the same user? With the SOM, you can do all of this, and more. Hey, our baby's starting to smile and coo a little bit!

Let me spend just a moment more on how the SOM works. The SOM is a library of JavaScript code usually installed in a folder named ScriptLibrary and placed directly below the Web application root (directly below the IIS virtual directory configured as an application. Tip: You will need to be careful where you place pages that use the SOM if you disable parent paths in your application as DTCs use relative paths when placed on a page at the same level or below that of the ScriptLibrary folder.).

The SOM also includes a Java class that provides the glue needed to make what are essentially remote procedure calls between client- and server-based pages (that's a little beyond the scope of this article, but yes, you can make calls from client pages to server pages and retrieve the results of those calls without leaving the client page to perform a round-trip). It is not necessary to have Visual Interdev to use the SOM. A complete copy of the SOM can be downloaded from Microsoft, at msdn.microsoft.com/scripting. This is a site all Web developers should visit early and often (in addition to, of course, WebReference.com). I'll focus on using the SOM in ASP pages, as most developers seek to create cross-browser compatible pages.

Next: Using the SOM

This article originally appeared in the July 6, 2000 edition of the WebReference Update Newsletter.

Comments are welcome
Written by Gordon Rose and

Revised: July 7, 2000

URL: https://webreference.com/new/som.html