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

Re: controls and instance nodes

From: David Landwehr <david.landwehr@solidapp.com>
Date: Mon, 20 Feb 2006 17:48:07 +0100
Message-ID: <43F9F2C7.4000906@solidapp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT