Skip to main content

Data Binding in XUL - Lessons for JDNC

Posted by hansmuller on May 5, 2005 at 5:38 PM PDT

Another entry into what I hope is a short series of blogs about
different approaches to data binding. My goal is to provide
some perspective for the data binding discussions in the
Java Desktop Network Components -

JDNC

project. A few weeks ago I wrote

Data Binding in Laszlo - Lessons for JDNC

and before I'm done I hope to cover Avalon and JGoodies binding.

In Browser/HTML applications data binding is often accomplished on the
web server by replacing variables in a "template" HTML file with the
string representation of live data values. Despite the infinite
number of design options for web application elements like template
syntax or template variable lookup, it seems as though every
conceivable possibility has been enshrined in someone's custom web
application framework. Over the years the design landscape has
become cluttered with these shrines, their developers, and the
wreckage left behind by the usual internecine warfare.

More recently web application frameworks have emerged that do much of
the data binding work in the browser itself. Requesting raw data from
the web server (or posting new data to the web server) and dynamically
building the DOM for an HTML GUI is well within the capabilities of
moderately portable JavaScript and modern browsers. Typically data
and templates are encoded with XML. This new design landscape has
been christened AJAX (Asynchronous JavaScript and XML), and browser
developers are enthusiastically staking out real-estate for new web
app framework design ziggurats.


XUL

is not new and this isn't a blog about AJAX or web applications.
I just wanted to write a little bit about how data binding appears
to be supported in XUL, using XUL templates. If the first
couple of paragraphs
have left you wondering if you really possess the will to read all the
way to my conclusions at the end, here's a shortcut to the exit: I don't
think XUL templates are a good way to define data binding. I have a
feeling that even some of more fervent XUL advocates would agree on
this point. I also think that anyone who's managed to read and
comprehend the RDF documentation deserves a medal and a vacation.

This blog isn't an introduction to XUL either. Suffice it to say that
XUL is an XML schema for defining Mozilla browser extensions and
browser based application GUIs. It's important because it's part of
Firefox and Firefox is hot.

Using templates for data binding in XUL is a bit like using
Javascript to construct a DOM in the sense that in both cases the
binding process takes place in the browser. The XUL template enables
specifying bindings in terms of what XML text (XUL source code) should
be generated, rather than rough and ready DOM hacking. A XUL template
is an XML file that contains template elements which
produce XUL source at runtime. XUL templates operate on data
represented as a graph, using RDF (lots more on RDF below).

The basic structure of a data bound XUL document is roughly:

<?xml version="1.0"?>
<window
  xmlns:html="http://www.w3.org/1999/xhtml"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  ...
  <vbox datasources="my-RDF-data.rdf" ref="urn:root">
    <template>
      <rule>
        <conditions> ... </conditions>
        <actions> ... </actions>
      </rule>
    </template>
  </vbox>
  ...
</window>

The RDF graph of data that the templates will bind to is specified
by the datasources attribute of an enclosing GUI container. In
this case that's a vbox (vertical layout box) which also names
the logical root node for the graph.
Each template element in the file has a set of conditions. Conditions
are expressions that get unified with the graph, and (shades of Prolog)
cause expression variables to be bound to data graph nodes.
These variables are substituted into the actions to produce the
template's data bound XUL source code.

If you're interested in a complete example, take a look at the

XUL Template Primer

on the Mozilla.org site.

My take on this approach to specifying data bindings is that it
makes the common case, binding data lists and objects to lists and
form GUI components, difficult. The process of unifying rule
expressions with subsets of the data graph to capture references to
nodes that will be substituted into the template's actions, is
difficult to explain and it's difficult to justify given the common
case. Harsher criticisms of XUL templates exist, e.g.

Why XUL Templates are a Waste of Time
.
I can't muster anything close to that much venom however I've
only looked at the documentation and some examples. The other problem
with XUL templates is the data encapsulation layer - RDF.

RDF (Resource Description Framework) is an
graph based data encapsulation. Arcs in the graph are defined as
"predicates" that link a "subject" node and a target or "object" node.
An RDF document contains subject/predicate/object triples that
collectively define a graph. Here's an example that dispenses with
the usual RDF XML notation:

   JoeBlogs firstName "Joe"
   JoeBlogs lastName "Blogs"

These two subject/predicate/object triples define a graph with
three nodes: JoeBlogs, "Joe", "Blogs" and two arcs: firstName
and lastName.

Although it's possible to model any data type with RDF, some types seem
to suffer for the encoding. Most JDNC applications are based on data
that is most naturally described as lists of objects with attributes.
As you can see from the example, defining an object's attributes
as arcs is straightforward, although perhaps not as straightforward
as a more conventional encoding, like:

   

List elements are related to the subject list itself with a predicate
that defines the object element's one-based position in the list.
Using the usual abbreviations, that's something like:

MyList rdf:type rdf:Sequence
MyList rdf:_1 myListElement0
MyList rdf:_2 myListElement1
MyList rdf:_3 myListElement2

One other aspect of RDF that trades readability for generality is
that all three elements of each subject/predicate/object triple is
defined by a URI. URIs (think URLs) are globally unique identifiers
which means that, in theory, each triple means the same thing in all
contexts on any computer, anywhere, ever. OK, that's something
of an overstatement depending on what "mean" means. To really
marinate in this topic, check out section two in the

RDF Primer
.
Defining everything in terms of a URI exacts a big readability
penalty. The previous example might be written like this:

<http://www.sun.com/myRDFScope/examples/JoeBlogs> 
   <http://www.sun.com/myRDFScope/examples/predicates/firstName>
<http://www.sun.com/myRDFScope/examples/Joe>

<http://www.sun.com/myRDFScope/examples/JoeBlogs>
   <http://www.sun.com/myRDFScope/examples/predicates/lastName>
<http://www.sun.com/myRDFScope/examples/Blogs>

As you might expect, one can throw the usual XML and URI syntax
tools at this to reduce the textual weight of an RDF document.
For an example, take a look at the '.rdf' files that come with
your Firefox distribution.

Frankly, I find it hard to believe that the average developer
would have the patience to wade through the entire RDF specification
or the RDF Primer for long enough to completely understand it.
Even the Primer contains enough mind numbing passages
to frighten away all but the most dedicated reader. For example:

Note that asserting the reification is not the same as asserting the
original statement, and neither implies the other. That is, when
someone says that John said something about the weight of a tent, they
are not making a statement about the weight of a tent themselves, they
are making a statement about something John said. Conversely, when
someone describes the weight of a tent, they are not also making a
statement about a statement they made (since they may have no
intention of talking about things called "statements").

A developer with no greater ambition than to just put a list of customers
or account balances on the screen, is likely to be considering
a career change by the time they've finished with this material.
I found myself sobbing uncontrollably.

In conclusion, I'll just repeat the point I made earlier. I don't
think XUL templates represent an approach to data binding that would
be wise to incorporate into JDNC and I don't believe using RDF to
encapsulate data is practical given the density of the RDF
specifications.