Building a Better Object Model

An Interview with Visual InterDev 6.0 Co-Designer Steve Millet

MSDN Interview
September 2, 1998

Visual InterDev™ 6.0 introduces a new scripting object model. To get the story on it for MSDN readers we interviewed Steve Millet, who co-designed Visual InterDev 6.0 and led the development of its new object model.

For even more detail on the object model, see the technical article by Steve Millet (complete with Active Server Page code samples).

For a higher level view of Visual InterDev 6.0, be sure to read our interview with John Shewchuk, the other co-designer of Visual InterDev 6.0.

MSDN: Can you summarize the new scripting object model you helped create for Visual InterDev 6.0?

MILLET: It's an attempt to add a symmetrical programming model for Active Server Page (ASP) programming on the server and Dynamic HTML programming on the client, specifically an Internet Explorer 4.0 client.

MSDN: How does the new object model accomplish this?

MILLET: We've created a set of script components that basically have two implementations: one that runs in Dynamic HTML on the client and one that runs in an Active Server Page on the server.

For instance, a button or a list box can have a traditional control-like interface. That object model is available whether you're targeting the client or the server. In addition, we've created a new set of design-time controls (DTCs) that target these new script objects or components.

By simply dragging and dropping these design-time controls in the new Visual InterDev 6.0 WYSIWYG environment, you get a very Visual Basic-like experience. You can drag a button onto a page, have it expose a click event, and then write an event handler for it.

MSDN: How can an event like a mouse click that fires on the client get processed on the server?

MILLET: That's a good question. This is one of the things the new scripting object model and script components can do for you.

One common task that developers do with HTML and ASP programming is submit to the server a form or event that came from the client, and then use the server to figure out what happened on the client. Visual InterDev 6.0 can do that work for you. It can automatically map a button click on the client to a URL and then into an entry point in your Active Server Page, as if you implemented a button click on the server.

MSDN: When you developed this object model, did the Visual InterDev team test it with other browsers besides Internet Explorer?

MILLET: Yes, we did, although our client-side implementation is specifically targeted for Internet Explorer 4.0 and Internet Explorer 5.0, in order to take advantage of the Dynamic HTML and Document Object Model that Internet Explorer exposes.

To reach Internet Explorer 3.0, Netscape Navigator, and other non-Microsoft or old browsers, your application should do its work on the server. We've gone to great lengths in the server-side implementation of the Visual InterDev scripting object model to make sure all these reach scenarios work. We've done a lot of testing with Navigator 3.0, Navigator 4.0 and Internet Explorer 3.0.

MSDN: Did you have a hard time getting the Visual InterDev 6.0 object model to work with those "broad-reach" browsers?

MILLET: It definitely was a challenge, because there were quirks with the scripting languages, how they handle form submissions, and so on. But they were all similar enough that we managed to get the object model working on all of them. It was more of a testing headache than a coding headache.

MSDN: If the new scripting object model targets Microsoft's implementation of DHTML in Internet Explorer 4.0 and above, doesn't this limit the number of developers who will want to use Visual InterDev 6.0?

MILLET: If you really want to take advantage of DHTML, that's true, you have to make a conscious choice to target Internet Explorer 4. But as I explained earlier, Visual InterDev 6.0 has two implementations of its scripting object model.

If you use the new design-time controls in Visual InterDev 6.0 to target script objects, we've made it easy to flip the switch. You can start designing a page for reach and when you're done with it, copy the page and flip the switch. All your Design-Time Controls will then target the dynamic HTML implementation in Internet Explorer 4. This gives developers a symmetrical programming model for both scenarios, using the same object model.

MSDN: What exactly do you mean by "flip the switch"?

MILLET: When you bring up the page designer in Visual InterDev 6.0, there's a document property called DTC target platform that you can set. There are basically two platforms it supports: Active Server Pages running on the server, or DHTML running in Internet Explorer 4.0.

You can individually target a DTC for either of those scenarios, independent of what the page says.

MSDN: What would you tell developers trying to decide which of those two scenarios to design for—broad reach or the latest rich Dynamic HTML technologies in Internet Explorer? How can they decide whether to build applications that do most of their processing on the server or target client-side Dynamic HTML?

MILLET: It really depends on the target audience you're trying to reach. For most broad-reach Internet applications, you'll probably choose to do your processing on the server. That's just a fact of a life.

Most big Web sites such as Amazon.com try to achieve maximum reach to the maximum number of browsers running on the maximum number of platforms. If your application is running in a controlled intranet environment where you know everyone has a Win32® box with Internet Explorer 4, you can take advantage of a richer client. You can have your applications do most of their work on the client and take some of the load off your servers.

With Visual InterDev 6.0, we tried to make it easy to build applications for both of these scenarios. It's not an all or nothing proposition with Visual InterDev 6.0. By giving you the same programming model and object model for both scenarios, it's easy to create a page that targets both. In the past, creating applications for two different target browsers required very different programming. Now the programming is very similar.

MSDN: When developers use Visual InterDev 6.0 to build an application that does most of its processing on the server, does the scripting object model make it easier to manage the state of components, such as the items in a list box?

MILLET: Absolutely. That's one of the big advantages of using the scripting object model for server processing. On a client, if you fill a list box with items and then a user comes along and interacts with the list box, the state of all those objects on that page is maintained. That's because you never leave the browser.

When your application has to execute a round trip for every user viewing an Active Server Page, the state of that page must be maintained. Developers perform a lot of tricks today to try to track the state of the page, such as putting state in hidden fields or in session variables on the server.

In Visual InterDev 6.0, the components in the scripting object model do all that for you. Let's say I write some code on the server to add 10 colors to a list box and then send that page to the client, where a user punches a button to add a new color to the list. When the application returns to the server to get that list box change event, all it really needs to do is add the new color to the list. It doesn't have to remember all the existing colors in that list before, since the script object for the list box maintains its state.

We play this trick by using hidden fields to round trip the state. The programmer doesn't have to think about that problem anymore. We do it all for them.

MSDN: How does the scripting object model in Visual InterDev 6.0 work with the Dynamic HTML object model in Internet Explorer 4.0—the Document Object Model? Do they conflict in any way?

MILLET: No. This is what I was talking about earlier when I said Visual InterDev 6.0 extends the Document Object Model. Visual InterDev 6.0 doesn't create a new script object in its Dynamic HTML implementation. It expands methods and properties on the existing Document Object Model.

For example, in the case of a list box, Visual InterDev 6.0 exposes methods such as add item and delete item. In the Document Object Model, the interface for a list box is very HTML-like. Visual InterDev 6.0 adds extra methods and properties to create a more programmer-friendly object model.

MSDN: So to summarize, Visual InterDev 6.0 is becoming much more of a RAD tool, coorrect?

MILLET: Absolutely. That was one of our design goals, to try to bring the same simplicity to Web programming that Visual Basic brought to Win32 programming. It was challenging because we had these two targets: broad-reach, server-side processing, and rich, client-side DHTML.

We think anybody familiar with Visual Basic or Win32 programming in general will find Visual InterDev 6.0 very familiar.

--------------------

Steve Millet and John Shewchuk are development managers in the Microsoft Developer Tools Division. They have been collaborating on software projects for the past eight years, and together led the design of Visual InterDev 6.0.

Since joining Microsoft in 1993, they have developed a number of core technologies that went into Internet Explorer, such as the 2D layout and scriptlet technology in IE 4.0. Earlier, they helped develop a publishing tool for the Microsoft Network (MSN) code-named Blackbird. When Microsoft turned its online efforts toward the Internet, they expanded Blackbird into a Web development tool that eventually became Visual InterDev.