 | ||
|
| ||
| ||
|
| ||
Nancy Cluts
Developer Technology Engineer
Microsoft Corporation
August 3, 1998
The following article was originally published in Site Builder Magazine (now known as MSDN Online Voices).
I love that noun object. It's used everywhere in computer lingo: object-oriented programming (entertainingly referred to as OOP), object model, intrinsic objects, client-side objects, server-side objects.
How did such an easy term for thing become so complicated?
Isn't an object just an object? Perhaps, before software engineers got their hands on the word, but not anymore! If you're confused about when and where (on the client or server) to use an object, don't worry -- I'm here to give you a little general information about objects, and then talk about the difference between objects that will run on the client and objects that will run on the server.
An object is a bit of code containing some specific, reusable functionality and data.
An object can be a self-contained item to be plugged into other applications, such as a dialog box or a form. Or it can be a database or a chart, or even an application. For objects to work with applications or script, the object exposes the functions and data that the object wants to share, also called public functions and data. The object can also have functions and data that it doesn't share, known as private functions and data.
Language objects (that is, objects created in the programming languages Visual Basic®, C, or C++) are defined by their class. A class is what gives the object its characteristics. I like the Visual Basic documentation's explanation of how this works: A class is like a cookie cutter, and the object is like the cookie dough. The cookie cutter defines the shape and look of the cookie, while the dough is an instance of one cookie.
Software objects are more easily understood as components -- something that you use "as is." The script developer simply plugs the object in and uses the publicly exposed properties and methods provided by the object. A software object can be built in and used (that's the Window object) or an instance of it may be created and used based on the ID (identifier) of the object. An example of a software object would be the WebBrowser control. This control allows you to take advantage of the browser functionality without having to rewrite the code yourself. (See the section Reusing Browser Technology in the Web Workshop for lots of information about how you can reuse the built-in functionality of the browser).
An object model is a set of rules that an object uses in order to work and communicate with other objects, applications, or script. It's how you "program" an object (i.e., it is a programmable mapping of the functionality provided by a component or application). The Document Object Model (DOM) is specified by the World Wide Web Consortium (W3C). This group specifies standards for Web computing, such as HTML language and CSS specifications. Internet Explorer supports the DOM in its implementation, known as the Dynamic HTML Object Model.
Intrinsic objects are built in and ready to use. Visual Basic, Internet Information Server, and Internet Explorer all make use of intrinsic objects. Intrinsic objects are available to all scripts. Examples of intrinsic objects in Dynamic HTML are BUTTON, APPLET, and DIV. See the list of DHMTL Objects in the Web Workshop for more information.
Client-side objects are run on the user's machine. These objects are included in the client-side code via the <OBJECT> tag or the new Object statement. Objects that are useful on the client can provide some type of user interface, such as a form with validation or a set of controls.
Server-side objects are run on the server. Because these objects run on the server, they provide no user interface. Instead, they are useful for doing things such as working with a back-end database, providing server authentication, or managing subscriptions.
You don't have to use client-side or server-side objects. Objects are really just bits of code containing functionality and data that has been separated out into logical chunks. You can, if you choose, write code that you simply cut and paste over and over again, wherever you need it. But once you start using the same bit of functionality over and over, it makes more sense to package this functionality into an object.
Remember, if you are not using an object for some repeated functionality, each time you want to change that functionality, you have to make the same change every place you pasted the code. If you use an object instead, you simply change the code for the object and your script that uses the object will automatically reflect the updates. For example, let's say you created an object that handled output to different devices. When a new device becomes available, you can update the code for that object, and all other applications or scripts that use this object will automatically have the ability to use that new device.
If you are going to provide client-side objects, keep in mind that the person who is using your Web site will have to agree to download the object. If the client machine does not support downloading objects, or has not yet downloaded the most recent version of your object, you will need to provide some sort of down-level support on your Web page. On the server, you need to keep in mind performance. Your objects will need to be tested to ensure that they don't slow down your site. Weigh the performance and download size -- and ability -- of objects before you decide to use them.
There are objects that you can run either on the client or the server, as well as objects that are split into both a client- and server-side piece. These pieces, in turn, communicate across the wire using a protocol such as HTTP.
You use client-side objects to perform tasks that you either cannot do via a scripting language or that are done repeatedly. Many client-side objects are created to provide some type of user interface. The developer can then script these user-interface elements as desired. Without client-side objects, the developer would have to rely on intrinsic controls provided by the containing application (such as Internet Explorer or Visual Basic). Typical client-side objects are controls, such as command buttons or hierarchical trees, Visual Basic forms, dialog boxes, or even an Excel chart.
ActiveX objects are supported via the Component Object Model (COM). COM is a language-neutral object model. This means that you may choose any language that supports COM when creating or using an ActiveX control, including (but not limited to) Visual Basic, C, C++, or Java.
You can embed objects in your pages via the <OBJECT> tag. You can then use the ID attribute of the <OBJECT> tag or the DHTML Object Model to reference the object from your script. The OBJECT tag is supported by HTML version 4.0 to embed objects in script.
In the script below, you will see that these selections are made via something called PARAM NAME. This stands for parameter name. In identifying the object, the script also specifies a name (called the ID), a unique series of hexadecimal (base 16) numbers, called the CLASSID, and the default WIDTH and HEIGHT of the object. (If you are confused by what a CLASSID is, don't fret. We'll be covering that in another installment of this series.)
<OBJECT ID="StockList" CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83" WIDTH=0 HEIGHT=0> <PARAM NAME="UseHeader" VALUE="True"> <PARAM NAME="DataURL" VALUE="quotes.txt"> </OBJECT>
The Visual Basic documentation provides an excellent overview of what objects are and how they can be used in Visual Basic. It's available in the MSDN Online site 
.
Because server-side objects run on the server, they provide no user interface. If your server-side object does provide user interface, then the only person who is going to see it is the hapless Web administrator -- and he probably doesn't care to see some whizzy graphic; he's too busy fixing broken links.
Instead, server objects are useful for doing such things as accessing databases, providing server authentication, or managing subscriptions. The Microsoft Internet Start site uses the Microsoft Investor server-side object to provide stock quotes on the home page. If you'd like to read up on how the team uses this object, read my article Getting Content From the Web to the Client in Web Workshop.
Microsoft Internet Information Server (IIS) can be installed on your server, and supports both intrinsic objects and objects that you can plug in. IIS provides support for Active Server Pages (ASP) technology. ASP uses ActiveX server objects (components) to access databases and applications, and to process information. Intrinsic objects exposed by ASP include the Response, Request, and Server objects. See An ASP You Can Grasp: The ABCs of Active Server Pages for more information about ASP and how it uses objects.
Keep in mind that objects really are just bits of code and data that you can plug into your script or application. You can write your own or you can get them from others. You can use any computer language that matches the expertise of your development team (even COBOL!). Objects can be used over and over again for a variety of purposes and are much easier to manage than the old cut-and-paste throughout your code.
If there are terms in this article that leave you scratching your head, the first place to look is the MSDN Online Glossary. This glossary will give you a paragraph or two about commonly used terms related to Web development. Let us know about other terms you'd like explained or terms you'd like more fully explained.
Ever since MSDN Online developer-technology writer Nancy Cluts became a godmother recently, she's been making us offers we can't refuse.
To accompany this article, the MSDN Online Bookstore has assembled a special reference nook (okay, it's really a special Web page). All of the following recommended reference books are in stock (most at a 20 percent discount), and can be ordered online:
Special thanks to our pals at Computer Literacy for helping assemble this resource.
-- Nancy Cluts
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top