<application-components>
	<!--
		XML Syntax
		<application-components id = "{id}" rid = "{rid}" participant-id = "{pid}">
			<application-component>
				<![CDATA[
					custom-function-1:function(){
					
					},
					custom-function-2:function(){
					
					}
				]]>
			</application-component>
		</application-components>
		
		The "id" attribute identifies the component identifier.

		The "rid" attribute identifes a reference id used when loading the component through an engine
		configuration.  This has the advantage of registering the component with the rid as a friendly name
		in the context of the engine.  It has no other use at this item.
		
		The "participant-id" identifies the transaction packet name the component will use.  If the attribute
		is not specified, the component id is used.  Transactional components can be enabled/disabled via compile-time configuration.
		
		The transactional capabilities are used with statically defined handler prefixes of '_handle_'.
		This prefix is also required for events.
		
		Events can only be handled if the event list contains the desired event ahead of time.  This list must be configured at compile-time.

		The context of the script is the new instance of the application component
		this = context object
		this.getReadyState() = {int_state}
		this.getObjectType() = {str_type}
		this.getObjectVersion() = {str_version}
		this.getObjectId() = {str_id}
		this.getObjectConfig():{
			pointers:{
			
			},
			status:{
			
			}
		}
		
		this.getContainerId() = {str_id}
		this.getContainer() = {object}
		this.serveTransaction({event-name}) = {1:0}
			Example: this.serveTransaction('mouseout');


		A component definition SHOULD use a hash structure, but SHOULD NOT use the requisite opening and closing braces.
		Those are added automatically, and are left out here so that components can be compiled into the enginelater on.
		This uses NOT a valid hash structure, but the contets
	
		
		component_init:function(){
			/* invoked when the component code has been merged with a new application component instance */
		},
		component_destroy:function(){
			/* invoked prior to the window closing, the host container being destroyed, on another request to destroy the component, or when a sigterm signal was sent */
		}

		Engine follows a paradigm where the implementor - that which implements the current object - is the container.
		Prototypes:
		
			// not part of the API, but a helpful example
			getReferenceId:function(){
				var oRegistry = org.cote.js.registry.ObjectRegistry;

				/* oContainer = XHTMLComponent */
				var oContainer = oRegistry.getObject(this.getContainerId());

				if(!oContainer) return 0;

				/* ReferenceId = EngineID or specified id */
				return oContainer.getReferenceId();
			},
		
		
		Here is a description of application component containment using an HTML Form Field as an example.
		
		There are several object levels at play here, with the current context being
		the [application-component /] level.
		
		With normal HTML, this is easy because DOM-access methods such as
		the forms collection or getElementById may be used:

		<select id = 'oDemoRecipeType'>
			[application-component /]
		</select>
		<select id = 'oDemoRecipe'>
			[application-component /]
		</select>
		
		However, there are advantages to using the engine framework.
			- id's are not globally scoped
			- the element is extended by the xhtmlformcomponent

		It is possible to load an XHTMLComponent around an element, such that
		the following API structure will be created.
		
		[xhtmlcomponent]
			[xhtmlformcomponent /]
			<select rid = 'demo_recipe_type'>
				[application-component /]
			</select>
			<select rid = 'demo_recipe'>
				[application-component /]
			</select>
		[/xhtmlcomponent]
		
		In this case, there is no automatic association with an engine,
		so some sort of collection id may be specified when creating the XHTMLComponent.
		
		Instead of manually jacking HTML into the engine framework, the Engine configuration
		does this automatically.
		
		[engine]
			[xhtmlcomponent]
				[xhtmlformcomponent /]
				<select rid = 'demo_recipe_type'>
					[application-component /]
				</select>
				<select rid = 'demo_recipe'>
					[application-component /]
				</select>
			[/xhtmlcomponent]
		[/engine]

		
	-->
		
	<application-component id = "demo_component_1" rid = "demo_component_1">
		<![CDATA[

				component_init:function(){
					org.cote.js.message.MessageService.sendMessage("Component definition for " + this.getObjectId() + " loaded","200.3");
				},

				component_destroy:function(){
					org.cote.js.message.MessageService.sendMessage("Component definition for " + this.getObjectId() + " destroyed","200.3");
				}
		]]>
	</application-component>
</application-components>

