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/

Received on Friday, 19 June 2009 18:57:28 UTC