RE: Some questions about dialogs


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.


Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71

> -----Original Message-----
> From: []
> 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
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --

Inventive Designers' 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