- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Mon, 30 Apr 2007 13:14:06 +0100
- To: public-html@w3.org
Hi Matt, > 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. 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. I have two problems with that argument. The first is that authors will quickly come up against the limitations of WF2 and then need something else, so it's a false economy to create just a simple language. That's why Ajax libraries are proliferating, and becoming increasingly popular. The second problem I have with this view is that it is incorrect that XForms is too complex for the simple task, which means that authors looking to move beyond HTML forms would be best off starting with XForms, and learning more advanced techniques as they need them. At the moment that's not completely possible, because there are some quirks in XForms that mean that some simple things aren't quite simple enough. But if we can iron those few examples out, we will have a unified language that suits both simple use-cases and more advanced ones. > 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. Why should a label contain the control? That seems upside down to me. And why does an output control have a calculation property? That doesn't seem very MVC; we should either say what the value of the output is (which might in turn be the result of a calculation), or we should say that some new value in the model is created via a calculation, and the output refers to that. 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; * 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. 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 Monday, 30 April 2007 12:14:15 UTC