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

RE: controls and instance nodes

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 20 Feb 2006 12:11:09 -0000
To: <www-forms@w3.org>
Message-ID: <00a001c63616$bbefe780$7e01a8c0@Jan>


>	Did the XForms Group consider the possibility that a control
> might be used in this fashion, or did the group decide that their
> should always be a 1to1 relationship between instance nodes and
> control?  What can be done to extend Xforms in the future to make
> this easier?

What you describe falls into a category that we have loosely called 'custom
controls'. It basically consists of encapsulating the functionality for a
more complex control so that it looks to the outside (i.e., your form) like
one widget, but internally is many more.

An example we often use to illustrate this concept is an IP address input
control. You can create this easily in XForms using four input boxes and
some dots between them, binding the input boxes to a simple instance. All
that then needs to happen is that when the user navigates away from the
group of four controls you concatenate the four values plus the dots and
then notify the form that contains the widget that the data has been
updated. Similarly, going in the other direction, if the data in the model
changes you need to let the custom control know, and it will crack open the
data into its four parts.

However, the key point here is that in terms of the containing form, all the
author needs to do is this:

  <xf:input ref="ip">

In other words, the fact that this control 'becomes' four more controls is
hidden. This is important since it keeps everything nicely encapsulated, and
because the underlying functionality of the control itself is unchanged, we
often call it 'skinning'.

One of the really powerful aspects of this is that it is recursive. If, for
example, you decided that any control bound to a node of type 'byte' should
be an integer entry box with up and down arrows, then your 'IP widget' would
just get this behaviour for free. Which means that if you were to create an
accessible version of the simple input box, but that understands voice for
example, then the 'IP widget' would just immediately become accessible since
it is no more than four simple input boxes. (I call this Recursive-MVC).

So, although none of the *interfaces* between the embedded controls and
their host form have been defined yet, plenty of proof-of-concept work has
been done. We (as in formsPlayer) have many controls working exactly like
this in version 2, showing maps, SVG clocks, and so on. Mozilla/FF have a
demo that 'reskins' their calculator demo to use SVG buttons. Both
formsPlayer and FF use XBL to define the bindings of the custom controls,
but it is also not difficult to use server-side translations to do the

To summarise:

  * not only is XForms a great language for defining
    forms and applications, but it is also a very
    powerful way for defining custom controls;

  * unfortunately, at the moment we don't have
    definitions for the interfaces, but it is on the
    WG's radar, and in varying degrees, already
    within implementations.



Mark Birbeck
x-port.net Ltd.

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

Download our XForms processor from
Received on Monday, 20 February 2006 12:12:29 UTC

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