[ engine demonstrations | engine overview | imnmotion.com | Stephen W. Cote ]
Engine Demonstration #5 is Part #2 in a short series of demonstrations on using Engine to create a shopping transaction. A shopping transaction is being defined as a customer browsing or searching through a list of products, selecting ones they want by adding them to a shopping cart, and making the purchase. Part #2 covers collecting user data from an engine configuration.
The files required for this demonstration are as follows:
The purpose of this demonstration is to expose an arbitrary HTML form to the engine architecture and require as few changes to the source as possible. The application should be ubiquitous whether the source of the form is XML, XHTML derived from a pre-existing HTML template, or an XForm. To that end, the implementation makes use of the configurable Reference Id attribute; rid throughout these examples. In Demonstration #4, the concept of an abstract definition was introduced. In this demonstration, abstract and component definitions will be expanded upon.
A generic XHTML package, org.cote.js.xhtml.XHTMLComponent, exists as a framework wrapper for otherwise normal XHTML. An HTML or XML node, a parent node reference, and an optional parent component id are provided to the XHTMLComponent constructor. The source node is copied into the parent node, and the component is registered with the Engine framework. Since this will most likely happen from within an Engine Service configuration, it is beneficial to specify the optional component id as the relative engine id using the ORA parameter values.
The form element source should nearly be identical to what is displayed on the screen, and the connection to the Engine framework should have no visible impact at all. From a client-side developer perspective, the form elements can be accessed either using a specified name or id attribute value as normal, by using the reference id through the Engine object, or through the XHTMLFormComponent package which works in conjunction with the XHTMLComponent and XHTMLFormComponent package. Using the reference id exposes a hook into the XHTMLComponent instance, and then also a pointer to the rendered HTML element. When form elements are created as XHTMLComponent instances, they can automatically be added to a component collection, such as XHTMLFormComponent. Access to the element values is then possible regardless of whether the element persists. Furthermore, elements that define a validation pattern can be automatically validated with the XHTMLValidator component. The end result is the form elements are used as needed while the validated form values persist.
The XHTMLFormComponent package can be used in conjunction with the validator component because the form elements, and the wrapper components, are created and destroyed everytime the configuration changes. Therefore, the developers don't have to worry about keeping track or re-synchronizing the values.
Event handling for the form elements can be specified either in the original source, or added at the last minute when the form elements have been drawn; both styles are demonstrated on this page. For example, the highlights are added when a configuration loads, and a wire-link is used (rather messily) for the button click.
If you see the text Engine Loaded in the following block, then the demonstration succeeded. If the engine is not started text does not vanish, you may be using an unsupported browser or there may be a bug in the software.
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.