- From: David Landwehr <david.landwehr@solidapp.com>
- Date: Mon, 20 Feb 2006 17:48:07 +0100
- To: Mark Birbeck <mark.birbeck@x-port.net>
- Cc: www-forms@w3.org
Giving this another thought, it would really be nice to have output as well as input "masks". So you can specify that a form control should represents its value in a specific way. E.g. that a date should be displayed as mm/dd/yy in a specific input control. I'm not sure how to present this, by maybe since such an output format is only styling a CSS property could be the way to attach the definition. Any thoughts? Best regards, David Mark Birbeck wrote: > Erik, > > I don't disagree with you, but I wasn't answering the question 'how would > you do this', I was answering the broader question 'has the XForms Working > Group ever considered...'. > > Input masks is a good way to go with this kind of thing, and I believe that > XFDL (an IBM form language that 'imports' XForms) already has such a > language feature. It therefore shouldn't be difficult to define how masks > might look in XForms. (You could also use the xf:extension element if you > wanted to do something now, before an updated spec was available.) > > However, once we had actually defined the syntax, for me the quickest way to > implement it would be using the 'custom control' architecture, since it > would take no time at all. That is of course an implementation detail, and > there are lots of ways to do it, but I'm talking more about an extension > architecture, rather than specific syntax. > > Another way to look at our approach is that we have a generic mechanism for > binding functional widgets to some form control--XBL. But to decide *which* > widget to bind to a control we use properties of the control as selection > criteria, such as the appearance attribute, values in the CSS class, the > underlying schema datatype of the node the control is bound to, and so on. > We could just add one more property--the presence of a mask attribute. > (Although I'd also want prefix and suffix attributes, whilst we're at it.) > > Regards, > > Mark > > Mark Birbeck > CEO > x-port.net Ltd. > > e: Mark.Birbeck@x-port.net > t: +44 (0) 20 7689 9232 > b: http://internet-apps.blogspot.com/ > w: http://www.formsPlayer.com/ > > Download our XForms processor from > http://www.formsPlayer.com/ > > >> -----Original Message----- >> From: www-forms-request@w3.org >> [mailto:www-forms-request@w3.org] On Behalf Of Erik Bruchez >> Sent: 20 February 2006 14:28 >> To: www-forms@w3.org >> Subject: Re: controls and instance nodes >> >> >> Mark, >> >> I find the idea of custom controls extremely interesting and >> promising. >> This is something we have been thinking about for a long time >> as well, an it is great to see that it is on WG members' >> radar. Orbeon will be one more voice in favor of doing some >> work in this area. >> >> But I am not 100% convinced that Richard's question >> necessarily requires such custom controls. Our approach to >> his problem was more in the line of introducing input masks >> to XForms. Input masks are a more specific solution, where >> you define a format for the input, and the XForms engine does >> the rest. >> >> Has anybody already started thinking about whether such input >> masks make sense in general in XForms, or even made >> proposals? What are the pros and cons of both approaches? >> Clearly, the "custom control" approach covers more use cases, >> but it is also likely to be more cumbersome for simple cases >> such as entering an SSN. >> >> -Erik >> >> Mark Birbeck wrote: >> >>> Richard, >>> >>> >>>> Did the XForms Group consider the possibility that a >>>> >> control might >> >>>> be used in this fashion, or did the group decide that their should >>>> always be a 1to1 relationship between instance nodes and control? >>>> What can be done to extend Xforms in the future to make >>>> >> this easier? >> >>> What you describe falls into a category that we have loosely called >>> 'custom controls'. It basically consists of encapsulating the >>> functionality for a more complex control so that it looks to the >>> outside (i.e., your form) like one widget, but internally >>> >> is many more. >> >>> An example we often use to illustrate this concept is an IP address >>> input control. You can create this easily in XForms using >>> >> four input >> >>> boxes and some dots between them, binding the input boxes >>> >> to a simple >> >>> instance. All that then needs to happen is that when the user >>> navigates away from the group of four controls you concatenate the >>> four values plus the dots and then notify the form that >>> >> contains the >> >>> widget that the data has been updated. Similarly, going in >>> >> the other >> >>> direction, if the data in the model changes you need to let >>> >> the custom >> >>> control know, and it will crack open the data into its four parts. >>> >>> However, the key point here is that in terms of the >>> >> containing form, >> >>> all the author needs to do is this: >>> >>> <xf:input ref="ip"> >>> ... >>> </xf:input> >>> >>> In other words, the fact that this control 'becomes' four more >>> controls is hidden. This is important since it keeps >>> >> everything nicely >> >>> encapsulated, and because the underlying functionality of >>> >> the control >> >>> itself is unchanged, we often call it 'skinning'. >>> >>> One of the really powerful aspects of this is that it is recursive. >>> If, for example, you decided that any control bound to a >>> >> node of type >> >>> 'byte' should be an integer entry box with up and down arrows, then >>> your 'IP widget' would just get this behaviour for free. >>> >> Which means >> >>> that if you were to create an accessible version of the >>> >> simple input >> >>> box, but that understands voice for example, then the 'IP widget' >>> would just immediately become accessible since it is no >>> >> more than four simple input boxes. (I call this Recursive-MVC). >> >>> So, although none of the *interfaces* between the embedded controls >>> and their host form have been defined yet, plenty of >>> >> proof-of-concept >> >>> work has been done. We (as in formsPlayer) have many >>> >> controls working >> >>> exactly like this in version 2, showing maps, SVG clocks, >>> >> and so on. >> >>> Mozilla/FF have a demo that 'reskins' their calculator demo >>> >> to use SVG >> >>> buttons. Both formsPlayer and FF use XBL to define the >>> >> bindings of the >> >>> custom controls, but it is also not difficult to use server-side >>> translations to do the binding. >>> >>> To summarise: >>> >>> * not only is XForms a great language for defining >>> forms and applications, but it is also a very >>> powerful way for defining custom controls; >>> >>> * unfortunately, at the moment we don't have >>> definitions for the interfaces, but it is on the >>> WG's radar, and in varying degrees, already >>> within implementations. >>> >>> Regards, >>> >>> Mark >>> >>> >>> Mark Birbeck >>> CEO >>> x-port.net Ltd. >>> >>> e: Mark.Birbeck@x-port.net >>> t: +44 (0) 20 7689 9232 >>> b: http://internet-apps.blogspot.com/ >>> w: http://www.formsPlayer.com/ >>> >>> Download our XForms processor from >>> http://www.formsPlayer.com/ >>> >>> >>> >>> >> >> > > > > -- -------------------------------------------- David Landwehr (david.landwehr@solidapp.com) Chief Executive Officer, SolidApp Web: http://www.solidapp.com Office: +45 48268212 Mobile: +45 24275518 --------------------------------------------
Received on Monday, 20 February 2006 16:48:11 UTC