The Scripting Object Model

To make Web application development faster and easier, Microsoft^® Visual InterDev™ provides the scripting object model, which simplifies Web application development by introducing a familiar object-oriented programming model to HTML and script programming. The model also greatly reduces the complexity and quantity of scripting required to write applications involving interaction between client (browser) and server.

The Visual InterDev scripting object model defines a set of objects with events, properties, and methods that you can use to create and script your application. You can create the visual interface for your application using design-time controls, and then write script to control the application using familiar object-oriented techniques.

The scripting object model allows you to create Web applications in much the same way you create applications in environments such as Microsoft^® Visual Basic^® and Microsoft^® Access.

The scripting object model is easiest to understand if you compare the scripting object model with how Web applications are created using the combination of ASP and HTML. To create a form, for example, you place HTML elements on a page, including text boxes, list boxes, and buttons. One of the buttons is typically a Submit button, which causes the form to be sent to the server, and which specifies an ASP page containing server script to process the form. Scripts on the destination page must manually examine the state submitted by the browser, and there is no association with the object that created the state.

Note   In Dynamic HTML (DHTML), controls on a page (and the page itself) are part of a document object model, but that model applies only to client scripts; it does not include server-side processing. In addition, the DHTML document object model can be used only with browsers that support DHTML.

In contrast, the scripting object model allows you to work with controls and with the page using standard object-oriented techniques. For example, rather than use the complex form submission process required by ASP and HTML, you can simply place a button on the page and write a handler for its onclick method to process the form. The scripting object model abstracts events such as onclick so that you can write handlers for them in either client script or server script.

Advantages of the Script Object Model

The scripting object model provides these advantages:

• Rapid application development using a familiar object-oriented model.   You can apply standard object-oriented techniques to developing Web applications. Because you have to write less script and can use simpler script, you can create applications more quickly and with fewer errors.
• Browser and platform independence.   You can use the scripting object model no matter what browsers will access your application. It works virtually the same whether you design your applications for server script (for maximum reach) or client script (for a better user experience, such as less flashing and fewer round trips to the server).
• Simplified forms.   You can create forms by dragging design-time controls onto a page in the same way you do in environments such as Visual Basic, and change their appearance and behavior using properties. You can process forms by writing standard event handlers and by calling methods — the scripting object model handles the complexities of posting the form and dispatching to the correct form-handling logic.
• Isolated application logic.   You can more easily isolate your application logic in discrete procedures — including procedures on other pages — rather than mingling it with user interface and navigation elements.
• State maintenance.   The scripting object model provides a mechanism for retaining the state of objects as control is transferred between the client and server. You do not have to manually manage state in hidden fields or session variables.
• Data binding.   The scripting objects can be bound to database fields so you can use them for data-entry and data-editing forms.
• Simplified page navigation.   The scripting object model provides a mechanism that allows you to navigate to another page by name rather than specifying the URL of the target page, and that can jump directly to any procedure on the page.
• Remote scripting.   You can execute server scripts from a page without navigating off the page. As in traditional client/server applications, this allows browser scripts to ask the server for a set of results, which can then be used in the browser for further calculations or to alter the page through DHTML.

Components of the Scripting Object Model

When you use the scripting object model, you work with a variety of objects. You use the same objects whether you are writing server-based applications (in .asp files) or pages with script that will be executed on the client browser (.htm files).

Note   The scripting object model is implemented using script stored in the Script Library. Do not alter the contents of the library, or components in the scripting object model will not work properly.

Enabling the Scripting Object Model

Before you can use the scripting object model, you must enable it, which constructs the scripting object model framework for the page.

Note   Visual InterDev design-time controls require the scripting object model. If you add a design-time control to a page that does not already have the scripting object model enabled, Visual InterDev prompts you to enable it.

To enable the scripting object model for a page

1. Right-click anywhere in the page away from an object or control, choose Properties, and then choose the General tab.
2. Under ASP settings, choose Enable scripting object model.

The Visual InterDev editor adds the scripting object model framework to the page in grayed-out blocks at the top and bottom of the page. You should not alter the content of these blocks.

Design-Time Controls and Script Objects

To create the user interface for your application, you can use the Visual InterDev design-time controls. A design-time control is a control used when you are working in the editor to create Web application's functionality. Design-time controls generate HTML text, script, and sometimes other components to implement at run time the functionality you are designing.

The Visual InterDev design-time controls include standard user-interface elements — text box, label, check box, list box, command button, and so on — that produce run-time text based on the scripting object model. Using the design-time controls makes it easy to create forms and bind to data by taking advantage of the features of the scripting object model.

Design-time controls have two levels of interaction. At design time, they are like controls that you might put on a form in an environment such as Visual Basic. You can interact with them visually in the HTML editor and set their properties to specify their appearance and behavior. Their actual purpose, however, is to generate script to be executed when the page is running. Therefore, when you set properties of a design-time control, you are actually changing the code that the design-time control generates.

When the generated code for a design-time control runs, it dynamically creates a script object. The script object is the object you write script against, setting its properties, calling its methods, and responding to its events.

The properties you set for a design-time control while working in the editor differ from those available at run time in the corresponding script object. However, they are related. For example, a design-time control's ID property is used to create the ID property of a script object at run time.

While designing your user interface, you can set properties for design-time controls in the Properties window or in custom property pages. Script object properties are not displayed in the Properties window, because they are run-time properties. However, they do appear in the IntelliSense^® statement completion drop-down list when you are scripting.

The design-time control also has no methods or events, because it never operates at run time. Script objects have predefined methods and events. As with script object properties, you can see a list of methods and events in the IntelliSense statement completion drop-down list. In addition, you can see the predefined events for a script object in the Script Outline window.

In some instances, a design-time control has a visual appearance at design time, but the corresponding script object has none. For example, the Recordset control, which controls access to data, is visible at design time so you can set its properties. But when the page runs, the script object created by the Recordset script object has no visible component, even though it has properties, methods, and events just like any other script object.

One of the advantages of design-time controls and script objects is that you can work with them the same way whether you want them to run on the server or the client. For example, if you want to target many different browsers, you can set the platform for the controls to "server," and all the design-time controls' generated code will run on the server. If you target the client as platform, the generated code will run on the client (though you must make sure that the client is capable of running it). But your interaction with the script objects, such as calling their methods, is virtually identical. The complex task of using server script to respond to a client event, such as a button click, is built into the script objects.

Page Objects

The scripting object model allows you to use Web pages as objects that you can reference in your scripts like any other object. By default, the current page is available as an object called thisPage.

Page objects can be referenced from other pages. This is useful for page navigation, especially if your application requires you to process a specific script on another page. For example, in your application you might process a form by navigating to another page that contains scripts for validation, database updates, and so on. In the HTML model, you post your form to the other page, and then write script on the destination page that would need to determine how the page had been called and how to proceed. By using a page object instead, you can call a method on that page object, and the scripting object model performs all the navigation and dispatching for you.

For example, in a page object called EmployeeList, write a function called DoQuery, and then expose it as method. From another page, you can execute this function by simply calling a method, as in the following:

EmployeeList.navigate.DoQuery("Accounting")

Using page objects also provides the means for remote scripting. Remote scripting allows you to call a script function process on an ASP page (to be run on the server) from client script without leaving the page. (The usual model is that you would have to leave the current page to execute a procedure at the server, even if the procedure is on the current page.) The client page therefore preserves its state, including where the script was executing before the call to the server was made.

Because remote scripts can also run asynchronously, you can provide a richer user experience. For example, you can perform database lookups to validate a user entry while the user is still working with a form..

 © 2002 -  2009 LBCInformation Corporation. All rights reserved Eng.Hanna Ata Lahoud.