RE: controls and instance nodes

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

Received on Monday, 20 February 2006 15:18:30 UTC