Re: readonly on trigger, etc.

Hi Erik,

On 30/04/07, Erik Bruchez <ebruchez@orbeon.com> wrote:
>
> 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.

But you could argue that sending different events to different 'view
elements' breaks some of the nice encapsulation we have in XForms. Why
should the model know about the type of item that is monitoring the
data?

Also, we need to be clear that the trigger for changing data in a
control is hidden from us, and is going on 'under the hood'. The XVC
event is a *notification* to anything that is interested, that the
underlying instance data has changed; it is not an indication that the
control should update itself, or whatever, and so whether a control
holds a value or not is irrelevant. For that reason, again, we
shouldn't be factoring out notifications, simply because we think we
know all the use-cases that particularly UI components will be put to.


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

I don't see the advantage of removing the consistency of @ref in the
UI, just to solve this problem, though--there are other ways of
looking at this. For example, I've argued before for the use of
@context throughout XForms, to allow the evaluation context to be
altered without creating a binding, and that would solve your problem
here, since the xf:group would not receive any 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.

I read this with some shock! Had I missed this discussion, I thought!
I'd certainly have argued against it if I was present. :) But calming
down and re-reading the XForms 1.1 spec I can't see that is says that
only some events are passed to xf:group. Are you certain about it? Am
I looking in the wrong place?


> 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.).

I'd really hate to see that happen. I'd much prefer to preserve the
simple--and reasonably consistent--relationship that's been
established between the model and UI controls.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 1 May 2007 09:28:34 UTC