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/
> 
> 
>

Received on Monday, 20 February 2006 14:28:01 UTC