The Atlas toolkit is not based on a special architectural pattern, like MVC related frameworks. So, the structure of an Atlas toolkit based application is rather simple. And it is exactly the same for the web and the desktop interfaces (and also will be the upcoming mobile interfaces), and you can use exactly the same code for both types of interfaces.
launch(...) is the main function, which launches, depending on the given argument, the web server or the desktop interface. Then, for each user action, through a callback or by calling explicitly a function, depending on which binding you use, you have just to perform the appropriate actions on the DOM, like:
Most of the DOM related functions are named after they corresponding DOM function, if relevant, or, at least, they refer to the DOM items of same name.
The Atlas toolkit handles two types of file, described below. Take also a look to the provided examples to see how they work.
.xsl files are those which filenames are given to the
setLayout(…) methods of the DOM object. That must at least be one to display the initial layout of the application. There can be others to provide the layout of sub-elements of the global layout.
.xsl files are referenced relatively to the directory containing the applications' main file.
This file is not mandatory, but it contains the entries you usually put
head section of an HTML page, such as style or script
definitions, or the
title tag. It has to be in the directory containing the applications' main file.
Through the XSL transformation, DOM elements can have special attributes which are handled by the Atlas toolkit.
An element can have a
data-xdh-onevent attribute, which are of
The value of
event can be all the available JS events, without the
on prefix. When the given event is launched on the concerned element,
the callback registered with the
register(...) (Node.js API) function and associate with the tag of value
action will be called, or the
getAction(...) function (other APIs) will return the corresponding
action alone can be specified, without
event, the action is then
associated with the default event for the given element. For example,
data-xdh-onevent="Submit" on a
button element is the same as
data-xdh-onevent="click|Submit", that is, as the onclick event is the default one for a button.
data-xdh-onevents attribute (with a final
actions on an element can be specified, by enclosing each
pair between parenthesis (
)) and separating them with a pipe (
This attribute can be used to dress an element with a jQuery widget.
The form is:
The needed CSS and scripts must be put in the
head.html file as
indicated in the widgets' documentation.
The activation of the widget is made by calling the
method of the
DOM object. For some widgets, this have to be made
after an eventual call to
setContent(s) to fill the widgets.
name is the name of the widget. In the documentation of the widget, you often find a instruction such as
name is simply
function (without the parameters).
parameters are the parameters of the widget you usually given to the
$(...).widget(...) instruction, with the enclosing parenthesis. If this
parameters contains a parenthesis or a pipe, they must be escaped with
the backslash character (
For some widget, to retrieve its content, you have to call a special function. In this case,
retrieving_function is where you put this function, the parenthesis and pipes escaped with the backslash character (
The links belows head to the detailed API of the corresponding binding.