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

Hi Anne,


On 30/04/07, Anne van Kesteren <annevk@opera.com> wrote:
> On Mon, 30 Apr 2007 14:14:06 +0200, Mark Birbeck <mark.birbeck@x-port.net>
> wrote:
> >> WF2:
> >> | <label>First name: <input name="firstname"></label>
> >> | <label>Surname: <input name="surname"></label>
> >> |
> >> | <output onforminput=
> >> | "value='Hello, ' + firstname.value + ' ' + surname.value" />
> >>
> >>    It's not quite a simple as your above example, but it's pretty close.
> >
> > I agree it's quite simple, but the fact that you say that XForms is
> > even simpler is an incredibly important point.
>
> For the record, how would you do the above in XForms? As a working
> example... The above can be saved as .htm and works. No strings attached.

I don't understand the question, because you are right that the above
can be saved as .htm and works, but that is only true if the browser
which opens the file has some access to a Web Forms 2.0 processor
(either built-in, as a plug-in, or via script). Now, since the same is
obviously true of an HTML document that contains XForms--again,
provided that the browser has access to an XForms processor, either
built-in, as a plug-in, or via script)--I'm wondering have I missed
your point?


> > The argument for Web Forms 2.0 is usually that XForms is too complex,
> > and that authors need something that's just a bit more powerful than
> > HTML forms, but not too powerful.
>
> Web Forms 2.0 is evolving forms in a way that's compatible with the web. I
> think that's the major argument. Ease of authoring is of course
> considered, but I don't believe that to be the main motivator.

I keep hearing this phrase 'compatible with the web', but it seems to
have no substance. I assume we agree that to get additional features,
we need to change something? And I would expect that we also agree
that the changes made to improve the popular languages like HTML and
XHTML are preferred to, say, XAML. But beyond that, all you are saying
is that you prefer the changes proposed in Web Forms 2.0 to the
changes proposed in XForms. That's of course entirely up to you, but
WF 2.0 doesn't have a monopoly on being 'compatible with the web'. In
fact, you could easily argue that XForms is way more compatible with
the current direction of the web, since it implements many of the
features that developers have turned to Ajax libraries for.


> > [...]
> >
> >> XForms Transitional:
> >> | <label>First name: <input name="firstname"></label>
> >> | <label>Surname: <input name="surname"></label>
> >> |
> >> | <input readonly calculate="'Hello, ' + firstname + ' ' + surname">
> >>
> >>    See that XForms Transitional is even simpler. When we hybridize the
> >> two, we get something that's conceptually identical to your example:
> >>
> >> WF2/XFT hybrid:
> >> | <label>First name: <input name="firstname"></label>
> >> | <label>Surname: <input name="surname"></label>
> >> |
> >> | <output calculate="'Hello, ' + firstname + ' ' + surname" />
> >
> > I'm not sure it's 'simpler' at all. [...]
> >
> > But anyway, putting that aside--since to some extent, issues like this
> > will be a matter of taste--the big loss by using your example
> > (WF2/XFT) is that you are no longer dealing with XForms, and you now
> > have three form languages:
> >
> >   * HTML for the past;
> >   * WF2/XFT for the so-called easy stuff;
>
> I'm not sure about XFT. But WF2 covers "HTML for the past" as well.

Of course. And I believe that this is also an area that should be
looked at in XForms. Although HTML forms are defined in terms of
controls that 'give up' a value at the point when data is submitted,
it is very easy to recast HTML forms in an MVC paradigm. Doing this
means that a standard HTML form can be interpreted as an XForm, and
then enhanced with additional features. As before, trying to make the
on-ramp smoother.


> >   * XForms for the easy stuff and the complex stuff.
> >
> > My argument is that the justification for a third approach that copes
> > with 'simple' examples is unnecessary, since XForms can already cope
> > with those simple use-cases. And not only does it cope with the 'easy
> > stuff', it has the advantage that it has a whole array of more complex
> > features available as the author begins to demand ever more
> > functionality.
>
> Maciej made some good arguments about what use cases XForms actually
> addresses that authors have trouble with solving today on the web. Also
> pointing out that far more complicated problems are already solved. I
> think it would be good if that's looked into some more.

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'.

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 Tuesday, 1 May 2007 11:39:46 UTC