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.
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!
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.
Written by Gordon Rose and
Revised: July 7, 2000