Re: controls and instance nodes

Hi Mark,

This custom control API sounds very interesting. Are the working group 
committed to creating such functionality and when can we expect to see 
the first public working draft of this specification?

Best regards,
David

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 12:32:35 UTC