[ engine demonstrations | engine overview | imnmotion.com | Stephen W. Cote ]
Engine Demonstration #10 shows effective component binding. The concept of an Application Component, as encountered in demonstration 7 and demonstration 8, is a just as the name implies: a generic component that can be associated with a component definition. The concept of effective binding then is the implementation of an Application Component as an extension to some other component or object. For example, a static declaration for a submit handler might point to a validation routine. An effectively bound form would be extended by an Application Component definition that includes the same validation routine. The difference is the feature is abstracted from the object, but can be tied to the object with a simple attribute in an Engine configuration, or a simple constructor for static HTML. Effective binding also serves to group sets of features together.
The files required for this demonstration are as follows:
The following example demonstrates binding static HTML form fields to Application Components by way of XHTMLComponents.
: User Name (focus and blur highlights)
: User Password (focus and blur highlights)
(mouseover and mouseout highlights; click event)
(mouseover and mouseout highlights; click event)
The following example demonstrates auto-binding of HTML fields specified in an Engine Configuration. If you do not see the select controls, then the engine did not load and there may be a bug, or you may be using an unsupported browser.
The Engine for Web Applications should start almost immediately. If this message does not disappear, there may be a bug with the software, a connectivity problem to the server, or you may be using an unsupported browser.
If the examples worked correctly, you would have noticed a couple highlight toggles on the text fields, shared highlights on the buttons, and a cascade-style select field. Consider the following diagram representing the architecture of this demonstration.
The only special differentiator for the form fields is an optional application component id attribute (acid). When any HTML element is bound as an XHTMLComponent, which may be before or after it is rendered, a series of processes are set in motion. Form elements are automatically registered with the XHTMLFormComponent, any Application Components are automatically started, and because the Application Components are Transactional, the HTML objects can start talking to each other.
Take a look at the three buttons again. When you move your mouse over Demo Button #1, all three buttons show their highlights. When you move your mouse over Demo Button #3, only Demo Button #3 and Demo Button #1 show their highlights. The buttons use separate Application Components, but Demo Button #1 and Demo Button #3 specify the same transaction, demo_buttons. Demo Button #2 identifies its own transaction, demo_buttons_2. When a non-transactional mouse event is invoked for Demo Button #3, it serves its own transaction, and also serves the transaction for demo_buttons_2, which includes Demo Button #2.
That is pretty amazing considering the three HTML buttons don't have an ID attribute, use the same mouseover or mouseout event, or possess pointers to the other handlers. What they do share is participation in transactions. When these buttons were bound to their own specific Application Components, they were automatically registered with the specified transactions. So, when one mouseover or mouseout event fires, the component serves the transaction and the other receives the notification. Even more important, though, is the Application Component handles the transaction, requiring the custom event handler to only serve the transaction as desired. In the case of Demo Button #3 highlighting Demo Button #2, the transaction name was needed.