Wobzilla integrates the user-interface into the browser, as a vast number content maintenance tools do. It currently runs only with Mozilla-browser Version 1.3 or later (and derived browsers like fireball and netscape). Decisive for the Mozilla was the large number of supported plattforms, keeping browser independence wasn't a priority for the first protoype. Apart from that, little Mozilla-specific extensions such as XUL or XPCOM are used. Wobzilla is largely based on the Web-Standards XHTML, DOM, XML, XPath and JavaScript. So maybe there will be an Internet Explorer- Version of Wobzilla someday, with the help of cross-browser toolkits like Dynapi.
Different from hardware-components, in software-technology the term component refers to the construction plan of which the computer constructs one or more instances of the component at runtime. This distinction is analog to the class/instance concept in OOP. Therefore we distingish in the following between view-components and view-component-instances, latter will be refered as views to simplify matters.
Views in Wobzilla are responsible for a given part of the output tree, thats the DHMTL-Tree rendered in the browser. Views can contain sub-views themselves (as of the compositum-pattern), the resulting data-structure will further be refered as view-tree.
The presentation-model in Wobzilla is a hierarchical
configuration of views. The class-Attribut of a
view-configuration contains the name of the
view-component. The following configuration describes
a view-tree that consists of two text-fields (both
20 columns wide). Each text-fields is embedded in a html
div element:
<wbz:view class="WbzContainer">
<html:div>
<wbz:view class="WbzTextField" cols="20"/>
</html:div>
<html:div>
<wbz:view class="WbzTextField" cols="20"/>
</html:div>
</wbz:view>
The graphic shows the view-tree that is generated out of the configuration, and the output-tree that is generated by the specific views
Using HTML as the output-language has some benefits over the traditional gui-drawing.
The mapping between data- and presentation-model is mediated
with xpath-Expressions (as in XForms). The expressions
are passed in the select attribute of a
view-configuration. That way every view is
assigned to a node in the data-model. Relative
xpath-Expressions are evaluated on the
data-model-node of the parent-view. The following
example shows a configuration of two TextFields that are mapped
to the first- and last-name of an author-entry.
<wbz:view class="WbzContainer" select="author">
<html:div>
<wbz:view class="WbzTextField" cols="20" select="firstname"/>
</html:div>
<html:div>
<wbz:view class="WbzTextField" cols="20" select="lastname"/>
</html:div>
</wbz:view>
The approach as introduced so far has many similarities to XForms:
Two important differences to XForms:
focus and validate.
In Wobzilla the processing logic is part of the components and the framework.
This allows the designer to use the declarative style of XSLT-programming and
shifts the more comlex issues of programming (like considering side-effects)
to the component and framework developer.
The last limition can easily be
shown in the following example. The XForms specification uses a
bookmarks
example to demonstrate the nesting of two
repeat elements. But an arbitrary nesting (as it
is quite common in most bookmark-managers) is not possible in
xforms. The next section shows an example of a recursive bookmark example
and how it can be done wobzilla.
Consider the following xml-file:
<folder name="Christophers
linklist">
<folder name="plans">
<bookmark name="Mensaplan" href="stw.uni-bonn.de/mensa.htm"/>
<bookmark name="Fahrplan DB" href="bahn.de"/>
</folder>
<folder name="projects">
<folder name="diploma thesis">
<bookmark name="XForms" href="www.w3c.org/xforms"/>
<bookmark name="Mozilla" href="www.mozilla.org"/>
</folder>
</folder>
</folder>
Transfering the bookmark example to HTML can be done with a handfull of XSLT expressions:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="folder">
Foldername: <xsl:value-of select="@name"/>
<xsl:for-each select="folder|bookmark">
<xsl:apply-templates select="."/>
</xsl:for-each>
</xsl:template>
<xsl:template match="bookmark">
Link: <xsl:value-of select="@name"/>
Url: <xsl:value-of select="@href"/>
</xsl:template>
</xsl:stylesheet>
But XSLT is a pure transformation-language. The data-document gets transfered to an output document in one step. Editing on the other hand involves constantly changing the data-source and synchronising the changes with the representative in the output. We call the necessary mechanism a mapping in contrast to a transformation. A central idea of Wobzilla is to use a mapping-mechanism that combines the expressiveness of XSLT with the component-concept introduced above.
The following configuration describes an editor for bookmark-documents in Wobzilla:
<wbz:stylesheet xmlns:wbz="http://wobzilla.sf.net/views">
<wbz:template match="folder">
Foldername: <wbz:view class="WbzTextField" select="@name"/>
<wbz:view class="WbzRepeat" select="folder|bookmark">
<wbz:create><folder/></wbz:create>
<wbz:create><bookmark/></wbz:create>
<wbz:apply-templates select="."/>
</wbz:view>
</wbz:template>
<wbz:template match="bookmark">
Link: <wbz:view class="WbzTextField" select="@name"/>
URL: <wbz:view class="WbzTextField" select="@href"/>
</wbz:template>
</wbz:stylesheet>
In comparison to the XSLT-version the following differences show:
wbz-Präfixes instead of xsl. Even though Wobzilla supports the XSLT-Syntax, the underlying concept is an extension of XSLT and not the original XSLT. This is accomodated by the use
of a differnt namespace.
xsl:value-of has been replaced with a TextField-view. The values are now
editable. Wobzilla also provides a wbz:value-of-component, but only for read-only views.
xsl:for-each has been replaces with repeat; repeat allows
the selection, removal and creation of elements in the data-model.
As above, there is wbz:for-each component for read only views.wbz:create declares the prototypes for the new folder or bookmark-instances, that can be created with the help ofrepeat.
Apart from this differences, writing Wobzilla-GUIs is quite similar to writing XSLT-Stylesheets. You won't have any difficulties in getting familiar with Wobzilla, if you had to deal with XSLT before.
To conclude the introduction we present a graphical overview of the described parts of Wobzilla. You will find a detailed explanation of the components and the mapping in the Wobzilla API also see How the framework works for an overview of the mechansims in Wobzilla.
