engine

API Documentation

[ engine overview | whitefrost.com | Stephen W. Cote ]

This document lists Engine members by package.

Contents

Utilities

Behind the core of the Engine framework is a set of utilities that provide access to XML resources and manage DOM events, to name a few. General, public utilites are provided in the following packages.

Application Driver

The Application Driver has no public methods or properties. Its main purpose is to perform two basic functions: publish a message via the Message Service when the window.onload event fires, and invoke the sendSigterm on the Object Registry when the window.onunload event fires.

The purpose of using Application Driver in this manner is to reduce any dalliance of Engine objects with non-UI browser events. It is also a central, generic object where application-level configuration data may be stored.

Message Service

The Message Service is used to send, publish, and subscribe to one-way application messages. It can be used for a variety of purposes, such as internal events and logging.

Object Registry

The Object Registry Service is used to manage objects based on a common object structure. By using the ORS, the web document namespace is not polluted with global identifiers and application objects are separated from the web page document object model.

Config

The Config psuedo-class was designed to load and hash XML-based configuration data. This is strictly a lightweight component.

The structure of the configuration data must be as follows: 

<root-name>
   <parent-name>
      <element-name attr-name = "name_value" attr-value = "value_value" />
   </parent-name>
</root-name>

The root-name is ignored, and the other name values are configurable using the public set-methods.

Primitive Wires and Wires

Primitive Wires and Wires are backbone implementations for creating action sequences.

Transaction Service

The Transaction Service is used to create a multi-channel communication between one or more objects. For example, the Task Service uses the Transaction Service to manage state and dependencies.

Objects may register with the Transaction Service if they are registered with the Object Registry and implement the startTransaction, endTransaction, and doTransaction methods. The startTransaction method must return true. The doTransaction should return true when it is finished with the transaction packet.

Task Service

Engine Service

The Engine Service is designed to create a runtime environment for Web applications. For example, one possible runtime environment might involve loading an external configuration file, using those configuration values to load additional configuration files and import and initialize components, and then parse by-page grammar for laying out UI elements. A simple declaration of <engine />, or defining the is-engine attribute, is all that is needed to initialize the environment and prepare one or more engines for use. Whether or not HTML declarations are made, a primary engine will load if the auto_load property is true or the loadEngines method is invoked.

Simple Transfer Service

The Simple Transfer Service arose while the web services component was being developed. The goal of the SimpleTransferService was to provide a basic mechanism for exchanging request and response codes, and simple data sets, with a known server.

Use of this service expects that the service accepts XML data via an HTTP POST request, and responds in kind with XML data. The structure of the XML requests and responses are as follows: 

<transfer>
   <request code = "{requestcode}">
      <param name="{name}" value="{value}" />
      <flag name="{name}" value="{value}" />
      <user-data name="{name}" value="{value}" />
   </request>
   <response code = "{responsecode}">
      <param name="{name}" value="{value}" />
      <flag name="{name}" value="{value}" />
      <user-data name="{name}" value="{value}" />
   </response>
</transfer>

Request and response codes should be the same, and be created from a runtime map where an even number is a failure and an odd number is a success. For example, the request and response codes for login might be REQUEST_NOTOK = 6, REQUEST_OK = 7, RESPONSE_NOTOK = 6, RESPONSE_NOTOK = 7. The Simple Transfer Service supports an internal handler for "synchronize", so that a request made to the server to "synchronize" will handle importing the request and response code definitions.

This is strictly a Barney-basic implementation.