W3C home > Mailing lists > Public > public-forms@w3.org > July 2013

Re: Dialog events

From: Erik Bruchez <erik@bruchez.org>
Date: Wed, 10 Jul 2013 09:09:54 -0700
Message-ID: <CAAc0PEVhiVUritNc=eXDh3HJRSE_czs5Ex4DPQhV12_inGv-CA@mail.gmail.com>
To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Cc: "<public-forms@w3.org>" <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
In order of preference for me: #3 then #2.

-Erik

On Wed, Jul 10, 2013 at 8:19 AM, Nick Van den Bleeken
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:
> All,
>
> Can everybody give his preference (or explicitly state that they don't have a precedence) about the proposed option by Erik (or propose others) by e-mail. We need to come to an agreement on this, and it is hard to get everybody on the call due to holidays.
>
> I can also live with option 2 and 3. And have a little preference towards option 3.
>
> Nick
>
> On 02 Jul 2013, at 23:22, Erik Bruchez <erik@bruchez.org> wrote:
>
>> All,
>>
>> During the last call, we discussed the issue of dialog events. See
>> also my original message. [1]
>>
>> Here is the issue:
>>
>> 1. I had initially proposed *notification events*.
>> 2. The current spec text proposes *action events* (events dispatched
>> by the show and hide actions).
>>
>> The question is: do we need both pairs of events, or one only?
>>
>> The main use case for notification events is dialog
>> initialization/clean-up. Ideally, event handlers for these can be
>> placed within the dialog itself, to make the code clearer. This means
>> that they must run when the implicit group within the dialog is
>> relevant. So the best time to dispatch them is just after the dialog
>> group is made relevant, and just before the dialog group is made
>> non-relevant, respectively. Names suggested:
>> xforms-dialog-shown/xform-dialog-hidden.
>>
>> The use case for action events is a bit less clear, but we have some
>> of those in XForms. They are typically cancelable. If they are
>> cancelable, they cannot be used as notification events, because you
>> don't want to, say, save information edited in the dialog if the
>> dialog is not actually closing. Names suggested:
>> xforms-dialog-show/xforms-dialog-hide.
>>
>> So there are the following solutions I think:
>>
>> 1. Make action events not cancelable, but that's not consistent with
>> other events.
>> 2. Only define notification events, and have the show/hide actions
>> immediately show/hide the dialog.
>> 3. Define the two pairs of events.
>>
>> I don't like #1 much, but I could live with #2 or #3. #3 is the most
>> general solution. The drawback is a bit more spec text and the
>> potential to mix-up the two events.
>>
>> Feedback requested.
>>
>> -Erik
>>
>> [1] http://lists.w3.org/Archives/Public/public-forms/2013Jun/0016.html
>>
>>
>>
>
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
Received on Wednesday, 10 July 2013 16:10:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:09 UTC