- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Tue, 21 Feb 2006 12:22:03 +0100
- To: Erik Bruchez <erik@bruchez.org>
- Cc: www-forms@w3.org
Let's put custom controls on the FtF agenda. Steven Erik Bruchez wrote: > > 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/ >> >> >> > >
Received on Tuesday, 21 February 2006 11:22:26 UTC