|
|
 |
As we have shown, the Behavior construct exemplifies several concepts from object-oriented programming languages and environments: - Hiding of the implementation details. Only the
Behavior interface is exposed to the caller HTML code (via the IMPLEMENTS tags). It allows you to change the implementation of the style without modifying the caller HTML elements, as long as the interface does not change. - Encapsulation of code. A
Behavior definition is enclosed in a single scriptlet file (soccer.sct in our Blinking Soccer example). Separating the behavior from the page contents eases the maintenance of both. No longer must the content expert deal with style and format. The style expert, on the other hand, can now focus only on these scriptlets, and does not have to deal with the page content. - Object-based definition. The definition of
Behaviors and objects is very similar. It includes both the data and the operations defined on it. No other data can be associated with a Behavior after its definition. No other operations can be supported besides the initially-defined ones. - Reusable code. The same
Behavior definition can be used by multiple DHTML elements. - Application Procedural Interface (API). The interface to a
Behavior scriptlet is well defined, similarly to a procedural interface. The contents page assigns values to the pre-defined parameters of the Behavior. The Behavior can send events back to its caller page.
  
|
|
