Wobzilla consists of two different facets.
On one hand Wobzilla is a component-framework, thats based on Clemens Szyperski:
A dedicated and focused architecture, usually around a few key mechanisms, and a fixed set of policies for mechanisms at the component level.(Wobzilla focuses on the creation of form and content-editors)
On the other hand wobzilla provides a set of components for the creation of rich graphical user interfaces. These components are further diveded by their usage.
First there are the mapper-components. Combined, they provide most of the functionality of a XSLT-Processor and allow a constant synchronisation between source and output-document.
In addition Wobzilla provides a set of manipulation-components. They allow the manipulation of the source-document. Typical components in this category are input-fields or tables.
The component architecture of wobzilla is based on Apache Avalon framework. Parts of avalon were ported to JavaScript within the scope of Wobzilla. A short introduction about the use of avalon and the core concepts of the framework is available under "How the wobzilla framework works".
The kernel of wobzilla is WobzillaEngine. It initializes
the main-window, the debugging-mechanisms and the basic menus.
It provides a set of basic services like loading and storing documents
or undo/redo functionality. See WobzillaEngine
for a full list of the provided services.
The configuration of the mapping components can be
written in a way that is according to the XSLT-specification. Only the namespaces are different.
Use xmlns:wbz="http://wobzilla.sf.net/views" instead of
xmlns:xsl="http://www.w3.org/1999/XSL/Transform".
There are shortcuts for each mapper-component named by the
xslt-equivalent. So in most cases simply replacing
xsl: with wbz: will do the job. For
instance write <wbz:apply-templates
select="title"/> instead of
<xsl:apply-templates select="title"/>.
The following table provides an overview of the supported
XSLT-language elements. Note that not all
XSLT-elements are supported. Some elements like
xsl:output don't make sense in the
Wobzilla-context. Others like xsl:attribute
and xsl:elements still have to many
implications for a simple implementation.
| XSLT-elementname | corresponding wobzilla-component |
| embedding into a host-language | WbzContainer |
| <xsl:stylesheet> | WbzMapper |
| <xsl:template> | configuration of WbzMapper |
| <xsl:import> | configuration of WbzMapper |
| <xsl:apply-templates> | WbzApply |
| <xsl:apply-imports> | WbzApply |
| <xsl:call-template> | WbzApply |
| <xsl:for-each> | WbzApply |
| <xsl:sort> | configuration of WbzApply. Handled with the wobzilla.sortFactory service of WbzMapper. |
| <xsl:if> | WbzChoose |
| <xsl:choose> | WbzChoose |
| <xsl:when> and <xsl:otherwise> |
configuration of WbzChoose |
| <xsl:value-of> | WbzValueOf |
| <xsl:variable>, <xsl:param> and <xsl:with-param> |
Handled with the wobzilla.variableFactory. Used in WbzContainer, WbzMapper and WbzApply. |
| <xsl:value-of> | WbzValueOf |
As the name suggests, this components allow the manipulation of the data-document, and thus indirectly the alteration of the view-tree which is created as a result of an evaluation of template-rules on the data-document.
| Function | wobzilla-component |
| Editing Text-field like html:input and html:textarea | WbzTextField |
| Editable lists, tables, trees and selecting of detail-views. | WbzRepeat |
| Component for simple alternatives (simplified WbzRepeat) | WbzChoice |