On Thu, 20 Jan 2005 11:54:06 -0600, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > Craig Wrote: > > > My current thinking is that we want the ability to have more than one > > > active dialog, so you can "push" from one dialog to another, then > > > "pop" back out. That's why I made it the dialog's responsibility to > > > clean itself up. > > > > > > I don't like the fact that the dialog has to know the attribute name > > > it is stored under (in session scope), but haven't figured out a way > > > around it yet. > > > > > > > > > Craig > > > > > > > I'm curious, could a dialog, or whatever it ends up being called, have > the ability to create "sub dialogs"? These sub-dialogs could be put > into a sandbox that the parent deletes upon exit.
Or even a stack, for that matter, so you can have arbitrary nesting. (Although that wouldn't deal with the multiple-window case where you might have a separate dialog going in each.) > Keeping the sub > dialogs in a collection of some sort would allow for multiple paralell > dialogs. Having a master dialor for the session that is always there > would allow for even the "top-level" dialogs to be removed and none of > them would have to know their own names anymore. Right? As it's currently implemented, the dialog comes into existence (and gets stored in session scope) as a side effect of being loaded as a managed bean. Therefore, right now, there's no notification to the framework to put that very first dialog into any sort of collection. That probably needs to change in order to deal with this particular issue. Duncan had a suggestion related to that, of using the plugin capability on the NavigationHandler to recognize when you are navigating to a dialog for the first time. That bears some investigation as well. > > Michael > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
