Re: Summary of November 6, 2009 group discussion on UI events

Hi,

thanks Erik for the summry. Some remarks from me, just for the record:

The concerns I tried to express address consistency: I do not want MIP  
changes be propagated by more than one event type, i.e. when we decide  
to propagate initial validity as part of xforms-enabled, we should  
drop xforms-valid/xforms-invalid completely. I just don't want to  
force the form author to listen to xforms-enabled *and* xforms-valid/ 
xforms-invalid when he/she is interested in validity only. Regarding  
the desired use case of an error list updated through events solely, I  
never meant that this had to be solved using only xforms-valid/xforms- 
invalid.

Regards,
Uli.

On 18.11.2009, at 08:43, Erik Bruchez wrote:
> 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
>

--
Ulrich Nicolas Lissé

Received on Wednesday, 18 November 2009 16:05:27 UTC