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.