Re: readonly on trigger, etc.

Mark & all,

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

Again, good point ;-)

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

I think this is a good approach, because consistent.

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

I think that this would be a good solution. I am quite convinced that
@context should be added in other places. xforms:action comes to mind
as well.

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

Mmm... Maybe I read between the lines, maybe not. Here is the text I
am referring to:

   "When a group becomes non-relevant, it must receive event
    xforms-disabled and then the XForms action handlers that are
    listening for events on the non-relevant group must be
    disabled. When a non-relevant group changes to being relevant, the
    XForms action handlers that listen for events on the group must
    become enabled and then the group must receive the event
    xforms-enabled."

It seems that this does not preclude an implementation to send other
MIPs to the group. However, it is not very clear whether it MUST send
other MIP events. Consider section "4.3.4 The xforms-refresh Event",
which dictates how MIP events are dispatched:

  "4. For each *form control* [...]" (emphasis mine)

Is xforms:group an XForms control? Not according to the categorization
of the table of contents! Which seems to indicate that the spec does
not mandate that MIP events other than xforms-enabled/xforms-disabled
be dispatched to xforms:group, bound or not. Nor does it explicitly
preclude it, but that's guesswork then.

Does anybody see more on this topic in the spec?

At any rate, too bad the LC period is now over otherwise the above
would be a good one I think. At any rate, if this is not fixed in 1.1,
it should definitely be made clearer in a subsequent release.

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

As I said above, I am almost convinced. In this light, I think we
need:

* A generalized @context attribute

* Make clear in the spec that the philosophy is any UI element bound
   to instance data, including xforms:group, receives
   xforms-value-changed and MIP events upon refresh.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 1 May 2007 09:52:39 UTC