[ engine demonstrations | engine overview | imnmotion.com | Stephen W. Cote ]
Engine Demonstration #7 shows how the Application Component is used to create dynamic, registered framework components. The purpose of the Application Component is to allow developers to assemble static and dynamic code and instrument it with the rest of the framework. The advantage to doing this is that code can be separated and imported as needed directly into a component, without creating a new script element for every request, and without polluting the global namespace with a multitude of variant code that may lead to collisions.
The files required for this demonstration are as follows:
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.
The structure of an Application Component is very straight forward, and the component can be assembled from within an Engine configuration, or stand-alone through script. In both cases, the script is delivered as a CDATA block via an XML request. The format of the script is a hash sans the requisite containing braces. For example:
<application-components>
<application-component id = "demo_component">
<![CDATA[
/* Invoked when component is initialized */
component_init:function(){
},
/* Invoked prior to component destruction */
component_destroy:function(){
},
/* Customization example */
myFunction:function(){
}
]]>
</application-component>
</application-components>
The Application Component constructor provides the rest of the context a developer needs to plug into the framework. By latching onto the optional component_init function invocation, a developer is able to immediately begin working with the registered object, work with any container, such as an Engine, or work with other Application Components. Also, by leveraging the existing framework, all sorts of wild and crazy business logic might ensue, such as defining a task to load a multitude of dynamic components in a specific sequence. The following code snippet shows how the Application Component used for this page modified the Engine to include some extra text and a link.
component_init:function(){
/* Retrieve the id of this object */
var oid = this.getObjectId(),
/* Retrieve the container id */
eid = this.getContainerId(),
/* Retrieve the component name */
cn = this.getComponentName(),
_e = org.cote.js.engine.EngineService,
o,
e,
_x = org.cote.js.xml;
;
/* Get a pointer to the container */
o = _e.getEngine(eid);
/* Validate the pointer */
if(_e.isEngine(o)){
/* Get the HTML element */
e = o.getContainer();
/* Add some HTML via the DOM */
var oP = document.createElement("p");
var oBr = document.createElement("br");
var oA = document.createElement("a");
oA.setAttribute("href","javascript:switch_config('" + oid + "','demonstration_7:next')");
oA.appendChild(document.createTextNode("Next ..."));
oP.appendChild(
document.createTextNode(cn + ' is using component id ' + oid + ' and is contained in an engine with the id ' + eid)
);
oP.appendChild(oBr);
oP.appendChild(oA);
e.appendChild(oP);
}
else{
/* Send a message if there was a problem */
org.cote.js.message.MessageService.sendMessage("Invalid container id","200.4",1);
}
One of the reasons for using the hash-style formatting is it is consistent with the rest of the internal project code structure. This means that a developer using the unreleased Engine SDK can create Application Components that are distributed (using the public version), or compile them (with the SDK) directly into the framework.