W3C home > Mailing lists > Public > www-forms@w3.org > February 2006

Re: controls and instance nodes

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Tue, 21 Feb 2006 12:22:03 +0100
Message-ID: <43FAF7DB.3010704@cwi.nl>
To: Erik Bruchez <erik@bruchez.org>
Cc: www-forms@w3.org

Let's put custom controls on the FtF agenda.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:16 UTC