W3C home > Mailing lists > Public > www-forms@w3.org > July 2006

Re: Use cases for multiple models

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 13 Jul 2006 21:03:34 +0100
Message-ID: <640dd5060607131303s3b4a2418x3903f22e1eba8693@mail.gmail.com>
To: "Erik Bruchez" <ebruchez@orbeon.com>
Cc: www-forms <www-forms@w3.org>

Hi Erik,

> I am wondering what use cases for multiple models XForms users have
> encountered.

Sorry I missed this!

One use of xf:model is as an 'object' that neatly encapsulates a set
of functionality that can be reused. This is not an absolute
requirement, but XForms has no easy way to provide the equivalent of
an object with some interfaces public, and some private and a model
provides a handy way to do this.

As an example, take something like OpenWFE, a rather nice workflow
engine that we've been working with recently for a customer. The
engine has a REST interface to do things like obtain a session, get a
list of workitems for a user, update a workitem, forward a workitem,
and so on.

Now, in our main form, all we want to have is a set of events that we
can fire at some object to say "start a session", "disconnect a
session", "get a list of workflow items" and so on. And in terms of
the data, all we want is the list of workflow items...we don't even
care what the session ID is, since that is merely used to make the
various 'calls' to the REST interface.

XForms doesn't give us any way to create objects with methods,
properties, and public and private data, but it's pretty damn close!
I'll illustrate.

In our model for OpenWFE, an event handler is like a public method:

  <xf:model id="mdl-workflow">
    <xf:action ev:event="workflow-create-user">
      <xf:send submission="sub-create-user" />

This means that anyone dispatching "workflow-create-user" at the model
will cause a submission to be invoked, but from the 'outside' of this
model, that is an implementation detail--all you need to know about is

Along with 'methods' coming 'in', we also have notification events
going 'out'; in this example, when a new user has been created
successfully (or not) we just send an event to the model itself, since
anything can register on the model for these events:

    <xf:dispatch target="mdl-workflow" name="workflow-create-user-done"
      ev:observer="sub-create-user" ev:event="xforms-submit-done"

    <xf:dispatch target="mdl-workflow" name="workflow-create-user-error"
      ev:observer="sub-create-user" ev:event="xforms-submit-error"

So now all the user of our model needs to know about is that they can
dispatch an event  *to* the model to create a user, and they can
register for two events *from* the model to find out if the user was
created successfully or not.

Alongside these methods and notifications, we have 'properties' which
are simply xf:bind statements:

  <xf:action ev:event="workflow-get-workitems">
    <xf:send submission="sub-get-headers" />


There are loads more 'interfaces' on our OpenWFE model, but this gives
you an example of each of the types.

In my view this technique is not a 'poor relation' of OO programming,
since with the events going in both directions, and the bind
statements, we are actually getting encapsulation--you could easily
replace my model with another for a different workflow engine.

We use this technique for many, many things (we have models for the
eXist database, retrieving the weather, getting a person's Amazon
wish-list, controlling tabs, and so on) and I think it works pretty
well, particularly since it plays to the MVC architecture of XForms.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Thursday, 13 July 2006 20:03:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC