Re: readonly on trigger, etc.

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