Re: HTML forms, XForms, Web Forms - which and how much?

Hi Henri,

> Based on the XForms spec, I still think it is fair to say that XForms
> is *meant* to be used only in XML-based host languages.

Well...I'd say 'originally intended', since I don't think anyone is
particular bothered that it is used in non-XML languages.


> > the reality is that it is being used today by lots of
> > people, in an environment that is essentially HTML.
>
> Given that XForms proper is already used in text/html (albeit without
> a spec) ...

Well, there is a spec--the XForms spec. I don't know if you mean that
there is nothing that specifically calls out HTML, and I suppose
that's true. There's also nothing that calls out SVG either, though.


> ...why is XForms Transitional needed then?

A good question. My *personal* opinion is that it is not needed. What
*is* needed is to ensure that the learning curve for XForms is a lot
less steep, and to review the language to make sure we don't put up
unnecessary barriers.

I'll give you an example.

We have a concept in XForms called 'lazy authoring', which allows an
author to simply define a user interface, and then have the underlying
data model created for them automatically. This is pretty powerful,
since you still get all of the benefits of an MVC architecture,
without having to know too much about what's happening under the hood.
An illustration might be this:

  <xf:input ref="firstname">
    <xf:label>First name:</xf:label>
  </xf:input>

  <xf:input ref="surname">
    <xf:label>Surname:</xf:label>
  </xf:input>

  <xf:output value="concat('Hello, ', firstname, ' ', surname)" />

If the user changes the value in either of the two input controls, the
output value is automatically recalculated, since XForms has a
powerful dependency engine at its core. For the form author it's not
unlike using a spreadsheet, in that you don't need to worry about how
or when the calculations are performed, they just are.

Now, that's great, and it's nice and simple for new authors. You'll
notice, for example that it's even easier than the very simple
approach used in Web Forms 2.0, since it avoids the 'event-oriented'
technique. But imagine now that the author wants to move on, and have
a slider on their form. Full of confidence from seeing their first
three controls working fine, they add the following mark-up:

  <xf:range ref="happiness" start="1" end="5">
    <xf:label>How happy are you?:</xf:label>
  </xf:range>

And wouldn't you know...this control won't appear on the form!

The reason it won't appear is that XForms as it currently stands says
that a range control can only be bound to data of type integer, and
although the lazy authoring mode has created a data element in the
model automatically for us, it has created one with a type of
'string'. To get our range control to display we need to add an XForms
model, an instance, and a bind element to indicate the integer
datatype.

Now, adding a model and bind statement is not enormously difficult,
and when you do add a model you get all sorts of other benefits from
XForms, like being able to define validation rules, indicating where
returned data should go, writing event handlers for data submissions,
and so on. But these are things the new author shouldn't yet be
concerned with, and certainly shouldn't have to know them to create a
slider. In other words, something that's very simple has been made
more tricky than it need be.

The good news, of course, is that it's easily fixed--in this example
there's no reason not to allow a slider to be used with data that is a
string. So finding these kinds of quirks is in my view what we should
be focusing on with XForms, so as to make the on-ramp to XForms much
smoother.

If we did that, authors would get the best of both worlds; a language
that let's you do the easy stuff as simply as HTML forms or the
proposed Web Forms 2, but that has a lot more juice in it than either
of those approaches, when you need to fulfill more complex scenarios.

It's the fact that XForms has a proper MVC architecture which makes it
so powerful at the top end, but that doesn't mean that we need to push
that aspect of the architecture to the novice author. So to return to
your question; in my view there is no need for a transitional language
as such--there is only a need for XForms. But that doesn't mean that
we shouldn't strive to make XForms easier to get into.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Sunday, 29 April 2007 22:13:41 UTC