- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Sun, 29 Apr 2007 23:13:33 +0100
- To: public-html@w3.org
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