|
|
|
|
|
|
|
|
|
|
|
Prior to the introduction of DHTML, the main method used for having a browser process actions within a page itself was to use an applet. The most common types of applets used on Web pages are Java applets. The main disadvantage of using Java applets is that the user must wait until an entire application is downloaded before they can begin viewing the material. Depending on the size of the applet, the user may spend a considerable amount of time waiting for those elements to load. On the other hand, when using DHTML the user does not have to wait until an entire application is downloaded before they can begin viewing the material. Instead the text and graphics are displayed first and then the code loads in the background. Using DHTML the user can start reading and clicking while the potentially large source code loads in the background. However like Java applets, DHTML will help reduce the number of actual connections made to the Web server. This should drastically help speed up Web applications since a lot of the time required to process an action is spent simply establishing a connection to the server.
Figure 1: Using constraints to specify the graphical layout of objects.
Re-compute formulas.
Constraints, like formulas in a spreadsheet application,
will force values to be recomputed automatically when
the values of entries change. For example in Figure 2,
the value of Total is automatically recomputed
whenever the values of housing, tuition, books,
entertainment, or miscellaneous are changed.
Maintain consistency between multiple views of data.
Graphical interfaces often provide multiple views of the
same data. When the user modifies the data by
manipulating the graphical objects in one of the views,
the other views must be updated to reflect the changed
data. For example, in Figure 3 constraints are used to
maintain consistency between the views of ice cream
flavors. If the value of the labeled box chocolate is
changed, then the bar chart is automatically changed.
Figure 2: Using constraints to re-compute formulas automatically.
Figure 3: Using constraints to maintain multiple views of the same data.
Cascading style sheets allow the style and location of page elements (such as text and graphics) to be specified separately from the content of the document. This separation of style and content allows a document to be more easily managed and modified. Shown in Figure 4 is an example of a DHTML document that uses a cascading style sheet.
1 <html>
2
3 <head>
4 <title>DHTML Example</title>
5 <STYLE TYPE="text/css">
6 h2 {font-size: 40pt; font-color: red; font-style: italic}
7 #object1 {position:absolute; background-color: #ffff00; left:70; top:80;}
8 </STYLE>
9
10 <script language="javascript">
11 function start() {
12 if (navigator.appName == "Netscape") { // USING NETSCAPE
13 if (document.object1.left < 600) {
14 document.object1.left = document.object1.left + 5; }
15 setTimeout(start, 20);
16 }
17 else { // USING Internet Explorer
18 if (object1.style.pixelLeft < 600) {
19 object1.style.pixelLeft = object1.style.pixelLeft + 5;}
20 setTimeout(start, 20);
21 }
22 }
23 </script>
24 </head>
25
26 <body onload="start()">
27 <h2>Redefined Level Two Heading Tag</h2>
28 <DIV id="object1">Example of a Layer</DIV>
29 </body>
30 </html>
In the DHTML document shown in Figure 4, line 6 redefines a level-two heading tag so that it now uses a font size of 40, red text, and is in italic. It also defines a DOM (i.e. object1) that is originally positioned 70 pixels from the left and 80 pixels from the top margin and has a background color of yellow. When the document is loaded into the browser, the ONLOAD event handler on line 26 calls the function start on line 11 which moves object1 to the right margin five pixels at a time waiting 20 milliseconds between moves.
When creating DHTML documents, the programming portion for most applications typically has to be written twice to make it cross-browser friendly. This is typically achieved by determining the browser and then writing the appropriate code for that specific browser. Even in the simple example shown in Figure 4, notice how the horizontal position of an object is specified using the left attribute in Netscape, whereas Internet Explorer uses the attribute pixelLeft to specify the horizontal position of an object. Since code typically has to be written multiple times to make it cross-browser friendly, this may explain the slow adoption of DHTML.
To help speed up the process of creating DHTML, our constraint solver when finished will convert a constraint into a cross-browser implementation. Shown in boldface below is an example of how a DOM object will be modified to specify a constraint for our new system. In this example, it specifies that the left of object2 is constrained to the left of object1.
1 <div id="object2" 2 style="position:absolute" 3 constraint="left:formula(object1.left)"> 4 <img src="image2.gif" width=100 height=100> 5 </div>The attribute constraint is a special attribute that is not recognized by browsers. Therefore, it will only be recognized by our new constraint solver. When our constraint solver parses this line, it will produce the necessary code to create a cross-browser application. Shown below is the code that might be produced to satisfy the constraint mentioned above.
if (navigator.appName == "Netscape") {
document.layers["object2"].left = document.layers["object1"].left
elseif ( // Using Internet Explorer
object2.style.pixelLeft = object1.style.pixelLeft
}
Figure 5: A link list showing the constraints for object1.
Now if the left attribute of object1 is modified, then the left attribute of object2 and object3 would be marked invalid. The constraint solver would then automatically re-compute the left values for object2 and object3. To prevent the constraint solver from entering an infinite loop, a valid flag will be used to marked constraints once they have been solved. For example, if the constraint (object1.top = object2.top – 50) was added to the list of constraints above, then the constraint solver could enter an infinite loop if a flag was not used to mark constraints that were already solved.
Related Work:
As of this writing, there is no other known work being
done on implementing browser constraints using
DHTML.