Summary of November 6, 2009 group discussion on UI events

All,

This is a quick summary of the discussions the working group had on
two Fridays ago, November 6, on the topic of improved UI events for a
future version of XForms. Presents: John, Leigh, Uli, Nick, and
myself.

This is based on my recollection so please send corrections / additions
if necessary.

I started by presenting and discussing the following proposal:

http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events

There seemed to be agreement from the group that some kind of rework
of the events would be beneficial. In particular the following
suggestions seemed to reach consensus:

* Controls hold state, including their current value and current MIP
  state.

* This state is used to dispatch UI events, as opposed to the current
  instance data marking system.

* Each refresh is like a checkpoint, and events reflect changes
  between state during a given refresh and state during the previous
  refresh.

* As per XForms 1.1, repeat iteration creation / destruction can
  dispatch events right away.

* Controls follow a lifecycle starting with xforms-enabled and ending
  with xforms-disabled.

* UI events should have more context information, including access to
  the target control's MIP state.

The discussion became a bit more interesting when it came to handling
MIP events (xforms-valid/invalid, etc.), with the following concerns:

* consistency of the solution
* number of events dispatched
* ease of use by the form author

The original proposal suggested that right after xforms-enabled, a
control would dispatch events for non-default values of the
MIPs. However, the proposal did not add that before xforms-disabled,
MIP events would have to be dispatched.

There was a specific concern (from Uli) that this would not allow form
authors to listen only to, e.g., xforms-valid/invalid. The form author
would in addition have to listen to xforms-enabled/disabled.

Options were discussed:

1. Follow the original proposal: dispatching MIP events just after
   xforms-enabled, but NOT before xforms-disabled.

2. Dispatch converse events before xforms-disabled. E.g. a control
   receives relevant, dispatches xforms-enabled, then becomes
   invalid. Before becoming non-relevant (dispatching
   xforms-disabled), xforms-valid is dispatched.

   Therefore somebody listening only to xforms-valid/invalid will
   properly track the control's validity state, assuming that when
   non-relevant the control is "valid".

   One concern with this solution was that more events are dispatched,
   and that it might be surprising to receive an xforms-enabled event
   for a control just about to disappear.

3. Allowing controls to keep state while disabled. This also removes
   the need for dispatching MIP events before xforms-disabled.

   One concern with this solution is the extra work necessary to keep
   state information possibly for entire subtrees of non-relevant
   controls, including repeat iterations, as well as yet unknown
   implications.

4. Not dispatching MIP events just after xforms-enabled and just
   before xforms-disabled. Instead, context information is present in
   xforms-enabled (and all MIP events in general) to access a
   control's initial MIP state.

   With this solution, MIP events besides xforms-enabled/disabled
   track MIP changes as seen by the controls. In fact they become MIP
   change events. To properly track a control's MIP state, tracking
   xforms-enabled/disabled is also necessary.

   One benefit of this solution is that it reduces the number of
   events dispatched.

The group did not reach a conclusion on this topic.

-Erik

Received on Wednesday, 18 November 2009 07:44:01 UTC