WXT-basics

The basic functionality of WXT is to build pages. This does not necessarily mean to build web-pages. It means in general that we may produce a page by extracting from many pages, transforming a page, splitting a page or any combination.

Below we focus on the obvious case where we will build a page from a template and one or more content-files by using a template which will be populated from a set of contentfiles. This is how it works

The script defines a page by telling which template to use and which contentsfiles to fetch material from. A simplified extract from a script may look like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<script version="1.0">
  <group ...>
    <template name="P" location="templates/p_template.xml"/>
    <page name="page1" template="P" location="index.html">
      <content location="content/b-index.xml"/>
    </page>

    <page name="page2" template="P" location="pub/p1.html">
      <content location="content/b-page1intro.xml"/>
      <content location="content/b-page1.xml"/>
    </page>
  </group>
</script>
    

It is not satisfactory to copy contentfiles completely into the template. We need a mechanisme that gives us the possibility to extract exactly what we want. The answer to this is XPATH and Processing Instructions. XPATH is a general tool for selecting any nodeset from a XML-file and Processing Instruction (PI) is a legal XML-element that may be picked upp by any useragent, of which WXT is an example. Assume for instance that our template has the following line:

<_wxt import xpath="//div[@class='main']/*"?>

This tells that the PI identifies itself as usefull for WXT (_wxt), it tells that WXT should interpret this as an order to import and it says that we should import the children of all div-elements that has an attribute class with the value main. These elements may be scattered around the contentfile, and may even exist in many contentfiles if the script says so.

A templatefile will normally have many such import PI's. This constitutes a very flexible and general mechanism to extract material from the contentfiles at will. If we control the contentfiles, we may realize allmost any construction job we may think of. This combination of the structure as described in the script and the PI's constitute the basic driving mechanisms in WXT.

Please note that even if we have used an example inspired by (X)HTML above, this basic engine in WXT works as well on any wellformed XML-dialect.

Transformations

We may introduce XSLT-transformations as shown:

Ti is XSLT-transformations that is applied before the template or contentfile is used by WXT. The output of these transformations must allways be wellformed XML. All files, templates and contentfiles, may have different transformations. Two files may have the same source and different transformations. We may even control the transformations by parameters which may be different for different files.

To is an output transformation. This is performed as the last operation before a page is written to file. The output of a To-transformation may be anything you may produce by XSLT: text, xml, html, XHTML, rtf or whatever. A simplified extract from a script may be like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<script version="1.0">

  <group ...>
    <template name="P" location="templates/p_template.xml"/>
    <transformation name="T1" location="trans/finaltrans.xslt"/>
    <transformation name="T2" location="trans/contenttrans.xslt"/>

    <page name="page1" template="P" location="index.html" transformation="T1">
      <content location="content/b-index.xml"/>
    </page>

    <page name="page2" template="P" location="pub/p1.html">
      <content location="content/b-page1intro.xml"/>
      <content location="content/b-page1.xml" transformation="T2"/>
    </page>

  </group>
</script>
    

Again I would like to stress the point that we still have not introduced any limitation on the type of files we are working with as rawmaterial. Any wellformed XML-construct will do.