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

Just want to add the rational of why 'we want' to change the eventing:
 - The events should be useful for the form author (we need an eventing system that makes life easy for Form Authors, this means simple rules of when events are fired)
   * it should be a reliable system to track lifecycle and state
   * Number of events send should be as low as possible (when we send to many events, the system becomes unusable)
   * it should be possible to know if the 'invalid' notification event send to a control just becoming enabled (if not send and state on xforms-enabled of course also solves this problem)

 - To validate point 1, it should be possible and straight forward to create a 'component' that can be re-used in every form that gives you an 'error summary', i.e. keeps track of the relevant invalid components in the form. With other words it should be possible to track validity and relevance of controls by just listening to all relevance and validity events.


Regards,


Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
Nick_Van_den_Bleeken@inventivegroup.com
http://www.inventivedesigners.com


> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of Erik Bruchez
> Sent: woensdag 18 november 2009 8:43
> To: public-forms@w3.org
> Subject: 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
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--

Received on Wednesday, 18 November 2009 08:13:11 UTC