On 9/15/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 9/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 9/15/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > > > On 9/14/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > In Shale, the closest analog to this is Dialog scope, and we're building > > the > > > concept of a scope instance per window/frame, independent of what that > > > window/frame is actually doing. > > > > I believe this requires usage of Javascript? So you would have > > listeners when a window is created and closed, right? I want to have a > > solution that works without Javascript. > > > Currently this doesn't take any JavaScript ... but note the code I'm > talking about here is currently in the Shale sandbox if you want to look > further at it. It will get merged back into the main codebase later. > > The basic idea is we rely on the fact that JSF saves and restores the > component state for us, so it uses a PhaseListener to store away the > conversation id as part of the component tree (when the page is rendered), > and restore the corresponding state (when the subsequent postback occurs). > In our case, it just exposes the "dialog context" for the conversation on > the current view as a request scope attribute ... I don't personally see a > use case for registering listeners on that conversation, but I suppose it > could be done. Does the above mean that the server does not get notified when a window is closed? So the session (or wherever the dialog context is stored) is not cleaned up immediately when a window is closed?
That is correct at the moment. Notification on window close would require javascript, right? Do you
have to use timer for removing unneeded dialog contexts? Or have you opted for something else?
We don't have a timer at the moment, but that's a good idea. How do you bind an ID to a window? Of course you can stick it into a
link, but what if I open a link that is not intended for a new window, with "open in a new window" command from a browser? I will not get a window ID, right?
There's three different ways that a window can receive a dialog id: * JSF navigation result that begins with a particular prefix * Programmatic call in an event handler (analogous to an Action.execute() method in Struts) * Special request parameter on the URL that says "please assign me a new dialog id for dialog xxxxx". If none of the above occurs, the new window will not be associated with any dialog id. The third alternative was specifically designed for popups -- the theory is that you'd manufacture the URL that will be used to create the window to include the appropriate dialog name. This approach also allows an additional cability that you can associate the dialog context of the popup window with the dialog context of the parent window that created it. This lets you use JSF expressions to pull data out of the main window and into the popup (at the start of the dialog) and push updated data back at the end -- even if the user has more than one window open running the "main" dialog. Cookies... I have to look again at how cookies work, but I always
thought that all cookies are shared by all browser windows, so I cannot have one cookie assigned to one window, and another cookie assigned to another window.
You're right ... that's not going to be a useful option. I should check the source code, but I would appreciate a high-level
two-liner before digging in :-)
The best overview is on the website[1], but the basic idea is that dialogs are modelled as a state machine composed of intermixed view states (a JSF page that is displayed and then returns a String outcome from the postback call to the action method), action states (JSF method expression call to an arbitrary method, that returns a String), or subdialogs. Transitions between states are driven by the the logical outcome strings. As I mentioned, the code inside shale-core today doesn't do all of this stuff. The "shale-dialog2" module in the sandbox is an abstraction of the programmatic interface to the facilities described above, with two implementations on different state machines ... one that is effectively equivalent to the legacy code currently in shale-core, and another that uses Commons SCXML under the covers. (Although this stuff is agnostic about the state machine to be used, it is *not* agnostic about whether JSF is there ... the functionality that drives everything is a custom JSF phase listener and navigation handler combination.) Craig [1] http://shale.apache.org/features-dialog-manager.html ---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
