- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Mon, 30 Apr 2007 16:26:34 +0800
- To: public-forms@w3.org
Mark, > The problem with this approach is that you are only referring to > controls that you know about--the ones in the XForms UI. But what > about controls in other languages that might make use of the XForms > model? Or what about an XForms UI control that is extended to do > something else, using something like XBL? This is a interesting point. I think it is reasonable to have a system where all UI components bound to instance data are notified of the full complement of value change and MIP events. However, and I didn't mention this in my response, we got to that idea of making a distinction between "value" and "non-value" UI elements not because of xforms:trigger, but xforms:group. Granted, in XForms, xforms:group is not a control, but a UI element. Nevertheless, you could still implement xforms:group as a component (with XBL or anything ele), and you can also bind xforms:group to instance data with @ref or @bind. In this particular case, it is confusing to me as a form author if xforms:group acts like a "value" control and receives xforms-value-changed events. Consider the following: <xforms:group ref="a"> <xforms:action ev:event="xforms-value-changed"> ... </xforms:action> <xforms:input ref="b"> ... </xforms:input> </xforms:action> Yes you could put the event handler within xforms:input, but if you don't for legibility purposes, then the handler will react to changes to the value stored in element "a" in addition to the value stored in element "b". And then you wonder whey you never read that xforms:group was actually "holding" a value, yet still receives xforms-value-changed events. Of course in XForms 1.1 we don't do what I describe in the above paragraph, because we special-case xforms:group by specifically mentioning that xforms:group receives xforms-enabled and xforms-disabled, but not the other MIP events. So my point here is: we already special-case xforms:group from the perspective of MIP events. We could as well special-case xforms:trigger, or then we could not do any "special-casing" but simply make a general distinction between UI elements that hold a value and those that don't, and then describe what UI elements do hold a value (xforms:input, xforms:select, etc.) and what don't (xforms:trigger, xforms:group, etc.). -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Monday, 30 April 2007 08:26:45 UTC