Apache Xang lets you quickly build data-driven, cross-platform Web
applications that integrate disparate data sources. The Xang architecture
cleanly separates data, logic and presentation. It is based on open industry
standards such as HTTP, XML, XSL, DOM and ECMAScript (JavaScript).
The Xang system extends the behavior of existing web servers to allow authors
to create applications that respond to requests and generate dynamic output
synthesized from different data sources.
A Xang application is defined by a single .XAP file that aggregates multiple
data sources, makes that data URL addressable and defines custom methods to
access that data. These custom methods can be invoked through simple HTTP
requests, via a Web browser or simple client side API.
Data sources are aggregated into one unified hierarchy via XML includes and
Java plug-ins which implement the standard DOM APIs. These plug-ins provide
two-way access to the data via the DOM API.
A .XAP file is an XML text file that defines the data sources, the mapping of
requests to methods, and the logic of the methods. The structure of the .XAP
file is a hierarchy of URL addressable elements.
This .XAP file is stored on a Web server and when a client requests this
file, the Xang system loads the file and passes the request on to the logic in
the file. The Xang system follows these steps:
- Identify the element addressed by the requested URL.
- Map the HTTP request to an application method on the targeted element
- Gather a body of script available to the command handler for the targeted
element
- Dispatch the HTTP request to the command handler
The structure of the .XAP file is a hierarchy of URL addressable elements
The 'name' attribute on Elements is used to perform a lookup based on the
path of the URL of the request.
For example: the URL http://localhost/samples/default.xap/inventory/products/product27/
identifies a Xang app "default.xap", and within that file there is
an element with the name attribute of 'inventory'. Within that element is an
element with a name attribute of 'products' and so on.
In a Xang application, methods can be invoked via URLs. The Xang engine will
use information from the URL request to location the target method to
invoke.
For example, with a sample application of
 | | |
|
<xap onGet='doGet();' onGetPurchase='run_purchase();'>
| |
| | |
the URL of http://localhost/samples/default.xap/?do:method=purchase
would be interpreted by the engine to invoke the method
identified by the onGetPurchase attribute of the root element.
The HTTP Method header (usually GET or POST) is used to identify the base
method and the 'do:method' parameter is used to identify the extended method.
These two things are put together to form the name of an attribute which is the
'handler' for that method. So onGetPurchase identifies the handler for an HTTP
GET request with a do:method parameter of 'purchase'. The default HTTP GET
request would be handled by the method identified by the 'onGet'
attribute.
The 'onGet' attribute defines the actual code that handles the request. This
code is expressed in script. This can be made independent of script language,
and in the future will be able to invoke Java directly.
This attribute is only a snippet of script, usually a function call. The full
body of script is pulled from a sub-element whose tag is <script>. This
script has the actual code definition.
In addition, the full body of script is the aggregation of all script
sub-elements at the target node, plus all the script sub-elements of each parent
of the target node. Essentially this creates a system of code inheritance.
Requests targeted to deeply nested child elements will be handled by code
declared and defined by some parent element.
The method handlers are 'inherited' from their parent elements. The
dispatching algorithm looks at the target element specified by the URL, and if
the requested method is not specified there, it traverses up the DOM tree to the
root. If no attribute is corresponding to the requested method is found, an
error is reported.
