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

Hi Anne,

> My question was what the equivalent XForms would be.

I see. I had already showed it, but here it is again:

> >  <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)" />


> As it was alluded to be simpler.

That's right, and not just by me; Matthew Raymond helpfully provided
the WF2 'equivalent', as follows:

> WF2:
> | <label>First name: <input name="firstname"></label>
> | <label>Surname: <input name="surname"></label>
> |
> | <output onforminput=
> | "value='Hello, ' + firstname.value + ' ' + surname.value" />

and immediately followed that with the comment:

>   It's not quite a simple as your above example, but it's pretty close.

I know that many programmers will feel more comfortable with an
'event-plus-script' approach, but it is a very limited technique. One
of the main reasons that developers started creating alternatives to
'event-plus-script' programming is because it is difficult to write,
difficult to read and analyse once you've written it, difficult to
debug whilst you're trying to get the damn thing working, and then
difficult to maintain when people come back in the future to ask for
new features (and the original guy who wrote it has gone off to work
at Google).

There's already been a discussion on performing calculations like the
ones above, using 'event-plus-script', but in my view a better
illustration of the declarative approach is the simple example of
mouseover hints or 'tooltips'. These are currently achieved in most
browsers by using @title, but we all know that this is limited. Most
Ajax libraries provide some kind of rich messaging feature, but you
still need to wire the messages up to event handlers. XForms, however,
provides the following:

  <xf:input ref="firstname">
    <xf:label>First name:</xf:label>
    <xf:hint>
      Please enter your <strong>first</strong> name.
    </xf:hint>
  </xf:input>

It's a nice and simple way to indicate that you want some tooltip text
displaying...but note that we don't say anything about the 'mouse in'
or 'mouse out' events, which means this mark-up could be used
unaltered in a system with no mouse, such as a telephone voice system.

To continue the example, what if we wanted to add a hint to the output
that shows the first-name/surname string, perhaps with an image in the
tooltip? In XForms everything is nice and consistent, and we simply
place another output in the hint:

  <xf:output value="concat('Hello, ', firstname, ' ', surname)">
    <xf:hint>
      Hello <xf:output value="firstname" />, this is a picture of you:
      <xf:output value="concat('http://pictures.com/', surname,
'.png')" mediatype="image/*" />
    </xf:hint>
  </xf:output>


> Compatible with HTML4 and DOM Level 2 HTML with modifications to those
> specifications that are required to support existing content is what I
> mean. XForms doesn't build on top of that.

But WF2 is not 'more compatible' than XForms just because you say it
is. WF2 requires new features, so does XForms. But they both make use
of DOM 2 Events, for example, and both can be incorporated into
existing browsers, if implementers chose to. (In other words they are
both an evolution, it's just that XForms solves a much larger range of
problems, and so provides more features.)


> > The complicated cases are not solved. But there is a reality that
> > seems to be ignored--developers are using Ajax in droves, because
> > current browsers are so under-specified and inconsistent in their
> > behaviour, so there is quite clearly a desire for more powerful
> > functionality. Although Web Forms 2.0 does some very clever things, I
> > don't think it provides enough at the 'top end' for authors looking to
> > get far more 'bang for their buck'.
>
> It's not clear to me what you mean.

I apologise. All I'm trying to suggest is that if we know that
developers want to do simple things and complex things, then we seem
to have two choices--create one language, or two.

Creating two languages seems easy enough, but the problem arises when
our developer wants to move from one 'mode' to another, i.e., they
want to do simple tasks today, but as they learn more, and get more
confident, they want to tackle more difficult jobs. Why should they
have to switch languages? Surely the most desirable goal is one
language that can cope with their evolution?

Now, you could argue that this is what WF2 is trying to do--extend the
existing language (HTML forms) to cope with more complex tasks. But my
argument is that WF2 has nothing at the 'top end', so really it gets
nowhere the level of complexity that authors are having to deal with
(as illustrated by interest in Ajax libraries).

On the other hand, XForms is clearly able to cope with the more
complex tasks. But it hasn't done itself any favours (as I've argued
in various places) by making some of the basic tasks authors need to
do unnecessarily difficult. It makes some basic tasks very easy too,
of course--as illustrated by the 'hint' example above--so the right
approach for XForms is to ensure that _all_ of the simple stuff really
is easy.

Now, the final step would be for XForms to extend downwards so that
HTML forms are recast as XForms forms, with carefully chosen default
values. This doesn't mean that authors need to understand MVC to get
going, but it does mean that they have an upward path when they need
it. For example, in XForms we have the idea of validating data against
an XML Schema on submission, and it would be very easy to define an
attribute on the form element to specify this, but to make it 'false'
by default.

In my view, therefore, the model is that HTML forms are already there
for very simple stuff, and people can use them as the like, without
learning anything new. XForms, however, is there to provide still more
of the simple stuff that we need every day (such as 'hint') but also a
lot of the complex stuff, which has the advantage of allowing authors
to move along the spectrum.

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 Thursday, 3 May 2007 10:52:00 UTC