RE: Some questions about dialogs

Erik,

Thank you for the good reply.

Until we know better how we will handle components I will write the text so that only one instance of a dialog can be open at once.

For the event sequencing, I think it is a good idea to do it in the default action of xforms-disabled. I was worried of people canceling the event (missed that it isn't cancelable), but this is indeed not possible.

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.inventivegroup.com


> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of Erik Bruchez
> Sent: vrijdag 19 juni 2009 20:57
> To: Forms WG
> Subject: Re: Some questions about dialogs
>
> Nick,
>
> > I started working on writing some text for the dialog module[1].
> >
> > And want the consult the group (and especially Erik) before doing
> > any further work on it.
> >
> >  * Can the same dialog be showed multiple times at once, if so some
> > kind of templating is required (or should this be handled by
> > 'components')?
>
> This is a funny one because since we implemented the dialog mostly for
> modal dialogs, we never came across the issue in our own
> implementation.
>
> But as suggested in the call yesterday, it does make sense for the non-
> modal case.
>
> Components can help, as the idea is that a component system has an
> instantiation mechanism which in fact creates a new instance of the
> dialog. That's certainly what happens with XBL (creation of shadow
> trees).
>
> This might still not cover the case where you don't know in advance
> how many dialogs you will open. As Charlie (I think) suggested, there
> is the use case of a "file explorer" dialog: you can imagine users
> opening as many such dialogs as desired.
>
> Now it would be ideal to support this, although AFAIAC it is not
> absolutely crucial.
>
> I think that if we support it, what is needed I think is language
> similar or identical to the creation of new repeat iterations: each
> dialog instance would create a new sub-tree. There are issues though.
> For example, with repeat, there is a notion of a current index, so you
> can dispatch an event from outside a repeat into an iteration, and we
> have a mechanism to address the correct iteration. But with dialogs,
> which one would be picked? The last dialog which was open? The last
> one which had focus? The one at the top of the "stack" of dialogs in
> the UI?
>
> >  * Is a dialog like a repeat and are the UI elements not in the tree
> > when the dialog isn't shown
>
> I think so, like a non-relevant group or a hidden case.
>
> >  * When introducing the SNB on dialog we also get the MIPs, when a
> > visible dialog becomes non-relevant we should hide the dialog, but
> > what is the event sequence? When is the xforms-dialog-close Event
> > dispatched? The problem I have is that the xforms-dialog-close event
> > should be displayed before all event listeners of the dialog are
> > disabled, but I don't know how I can accomplish this...
>
> The first question is whether we should use relevance to cause closing
> the dialog.
>
> At first I thought we should not, because in the same way that we
> wouldn't use relevance to cause the dialog to open, we wouldn't use it
> to hide it. A non-relevant dialog control would simply cause its
> content to become non-relevant, without actually closing the dialog.
>
> There is a problem with that, which is that there is not much meaning
> for a dialog to be open, but for the dialog control itself to be non-
> relevant.
>
> So I am now leaning towards thinking that we should indeed close it.
>
> Now, if we do, regarding event dispatch, we have a similar scenario
> with xforms-disabled:
>
>    "When a form control becomes non-relevant, it must receive event
> xforms-disabled and then the XForms action handlers that are listening
> for events on the non-relevant form control must be disabled."
>
> So you could have the same thing: xforms-dialog-close is dispatched to
> the control just before the event handlers are removed. This would
> have to occur during refresh, or as a result of refresh.
>
> Could we say that for a dialog, the default action of xforms-disabled
> is to dispatch xforms-dialog-close to itself? Since xforms-disabled is
> not cancelable, that should work just fine.
>
> -Erik
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>
> --
> 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 Saturday, 20 June 2009 17:33:51 UTC