- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 2 Jul 2013 14:22:44 -0700
- To: public-forms@w3.org, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
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
Received on Tuesday, 2 July 2013 21:23:31 UTC