Components, Components, Components
As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.
July 12, 2000
One of the more significant features for Microsoft® Internet Explorer 5 was DHTML Behaviors. DHTML Behaviors let developers create reusable components that could easily be used on Web pages. For developers who build applications for Internet Explorer 5, that capability was used heavily to reduce code size and increase reuse.
One of our goals for Internet Explorer 5.5 was to build on this functionality and make behaviors more powerful. One of the ways that behaviors were built was to aggregate HTML elements together. However, because this aggregation happened in the primary document, the components weren't completely encapsulated—not so good from a component point of view. We needed to fix that. To resolve the problem, we developed a technology called "ViewLink." The ViewLink feature lets you put HTML or other XML content in your HTC file, then link that document to the rectangle in the primary document where the initial tag is displayed. This causes the display of the second document to appear in the space reserved by your tag, but there is no object model leakage between these documents. You can find a more in-depth overview of this in What's New in Internet Explorer 5.5 and you can read the docs at Viewlink.
Also, while most behaviors could be built by aggregating existing HTML content, other developers needed to go down to the metal and write directly to GDI or a DirectX surface to create their intended effect. They saw the natural progression from ActiveX® controls, which own a rectangle, to the benefits of behaviors, which contribute functionality to a container but can leverage all the functionality of the other HTML or XML elements on the page.
For example, if you created a vector graphics control that could draw ovals using an ActiveX control or a Java applet, then you could draw only ovals. If you wanted to put text inside those ovals, you would have to write all of that code yourself. If you wanted tables, or vertical text, or Japanese language support, you had to write the code yourself. However, behaviors presented a different model.
Behaviors let you build your own XML tags and define how they would work. With a behavior, you define only the functionality of your container. However, you immediately get the benefit of all the functionality of the browser, because your new tag can contain any other content. The browser deals with rendering the content inside. For example:
<x:oval radius="100px"> Here is some text <B>Even bold text</B><BR> <TABLE BORDER="1"> <TR><TD>Or Even a Table</TD></TR> <TR><TD>With Many Rows</TD></TR> </TABLE> </x:oval>
The x:oval tag has to draw only the oval. The browser parses, measures, and draws all of the other content inside. If you think about building an old-style rectangular control with ActiveX or Java, you can see how much more difficult it would be to gain all of the functionality that you can get just from using behaviors. Your components would also be much larger, as you would have to carry all of the custom code with you. Also, you would have to invent special parameters and an object model so your content could be manipulated. Not so with behaviors. The behavior developer writes the code that makes it special, and inherits all of the functionality the browser has to offer.
Okay, back to drawing the oval. We needed to let people do that easily as well. The fix for this was a set of rendering interfaces, documented at Implementing Rendering Behaviors.
Building Flash Behaviors
One of the companies that was interested in behaviors and the enhancements made for Internet Explorer 5.5 was Macromedia. We had some interesting discussions about how Flash could be leveraged to create great behaviors for reuse using Internet Explorer 5.5 technology. One of the first things that came up was the creation of a set of high-level behaviors that encapsulated controls, such as a bar graph, a pie chart, an org chart, buttons, menus, and so forth. These could all be implemented as behaviors, with the parameters for them just passed as other HTML elements.
The example I'll review here is a bar graph. Check it out.
Here's the code to create the graph.
<MMflash:bargraph id="StockGraph" LABEL="Stock on Hand"> <PARAM VALUE="40" COLOR="red" LABEL="Computers" /> <PARAM VALUE="56" COLOR="blue" LABEL="Phones"/> <PARAM VALUE="13" COLOR="black" LABEL="Monitors"/> <PARAM VALUE="14" COLOR="yellow" LABEL="Chairs"/> <PARAM VALUE="12" COLOR="red" LABEL="Pens" /> <PARAM VALUE="20" COLOR="green" LABEL="Palm PCs"/> <PARAM VALUE="99" COLOR="blue" LABEL="Speakers"/> <PARAM VALUE="1" COLOR="black" LABEL="Headphones"/> <PARAM VALUE="31" COLOR="yellow" LABEL="Laptops"/> <PARAM VALUE="78" COLOR="red" LABEL="Books" /> <PARAM VALUE="43" COLOR="green" LABEL="CDs"/> <PARAM VALUE="20" COLOR="blue" LABEL="Scanners"/> <PARAM VALUE="87" COLOR="black" LABEL="Digital Cameras"/> <PARAM VALUE="3" COLOR="yellow" LABEL="Widgets"/> </MMflash:bargraph>
The first cool thing is that this component gets authored in the same way as any other HTML component. The second cool thing is that if you want to manipulate this component, you just manipulate the HTML elements.
Below the bar graph on the sample is a drop-down list, a text input, and a button. If you select a product type, put in a new value, and hit change, the value on the bar chart automatically updates.
This isn't achieved by talking to the Flash object model; this is done by changing the PARAM HTML elements. Here's the line of code:
StockGraph.all[SelectedProduct.value].value = NewValue.value
The user of this component doesn't have to have any deeper knowledge of the component's implementation. It's just treated as though it were a normal HTML element.
Macromedia has a complete SDK for these components.
Macromedia's work with Flash shows how component providers can seamlessly integrate their functionality with the browser functionality. Using this type of integration allows components to be smaller and simpler, and to leverage completely the power of the browser for their own functionality. As well, developers don't have to context-switch between multiple object models or syntax models to create new content. In the end, this makes it easer for component vendors to add value, and for developers to take advantage of that value.
Michael Wallent is Microsoft's product unit manager for Internet Explorer.