Reusable widgets can be created in Vexi by defining them in templates. Templates are plain text files with a '.t' extension and are XML compliant.

Templates are analogous to classes and are static. Their purpose is to create encapsulated instantiable components out of structures of boxes and associated JS code. It is possible to achieve the same effect by programmatically, in vexiscript, building up a box hierarchy and adding traps/functions to the boxes.

A Vexi template has a root XML node <vexi /> whose parameters are the namespaces accessible within the template.

 <vexi xmlns:ui="vexi://ui" xmlns:meta="vexi://meta" xmlns="vexi.widget">
     <meta:doc>This is for documenting the template</meta:doc>

     // static content may go here
     static.defaulticon = "default";

     // preapply followed by template
     <button />
         // template content begins here
         <icon id="icon" />
         <label id="label" />

         // JS code here
         icon ++= function(v) { $icon.icon = v==null ? static.defaulticon : v; cascade = v; }
         text ++= function(v) { $label.text = v; return; }

         $icon.icon = null;


     // static content may also go here



Namespaces are defined as parameters on the root <vexi /> node.

A namespace parameter has the structure 'xmlns:name="location"'. If the name is omitted, then it is used as the default namespace.

Namespaces are usually period delimited directory locations. For example, to declare a namespace that looks in the vexi/widget/ directory, we would use 'xmlns="vexi.widget"'.

Special Namespaces

There are three special namespaces, commonly known as 'ui', 'js', and 'meta', declared as 'xmlns="vexi://ui"' etc.

The 'ui' and 'js' namespaces give the template access to core features such as Box (ui) and Object (js).

The meta namespace is used for creating documentation which is ignored by the parser - thus can contain non-resolving references in XML and textual content that is not vexiscript.


Closed nodes declared before the principal node in the root node are preapplies. Preapplies allow multiple inheritance and are applied before the template.


Closed nodes declared after the principal node are postapplies. Postapplies are similar to preapplies, except are applied after the template.

Principal Node

There may be a single open node under the root <vexi/> node, and this is called the principal node. It contains the template instance content; a combination of XML content - anonymous nodes defining structure - and textual content - vexiscript that describes encapsulated behaviour.

Static content

Any textual content in the <vexi/> node is interpreted static content. It is executed once per application life-cycle. Accessible properties may be assigned and referenced here using the static keyword.

A template's vexiscript can access its static content by using the static keyword.

External templates may access a template's static content using the .. syntax. That is, considering a template 'bar' in named namespace 'foo' that has a static property 'prop', to access it use 'foo.bar..prop'.

Template Life-Cycle

A template is activated when one of the following occurs:

The first time, and first time only, a template is activated:

  1. The template is parsed to ensure XML compliance
  2. Its static script is executed

When creating an instance of a template:

  1. Preapplies are evaluated and applied consecutively
  2. Anonymous nodes are evaluated and built up depth-first
  3. The principal node is evaluated
  4. Script in the principal node is executed
  5. Principal node parameters are applied
  6. Postapplies are evaluated and applied consecutively


Copyright © 2011 The Vexi Project (vexi.sourceforge.net)