On Sun, 2 Jan 2005, Heath Borders wrote:
We could have some javascript code that could pull data from the server at the end of loading, and supply an identifier for the frame that way. Thus, if the user opens a new window, the code would be executed again, and it would get a different value. We would probably have to use code similar to what Google uses in Google suggest to make the request.
Yeah, that would probably do the trick, at the expense of an additional round-trip. But the expense would no doubt be worth it when you need this kind of functionality.
-- Martin Cooper
On Sun, 2 Jan 2005 20:06:09 -0800 (PST), Martin Cooper <[EMAIL PROTECTED]> wrote:
On Sun, 2 Jan 2005, Travis Reeder wrote:
Responses below:
Craig McClanahan wrote:
My personal opinion is that a scope "longer than a request but shorter than a session" is something that should be built into the Servlet API, because it's quite relevant across all the technologies built on top of servlets. It would seem this should be a prerequisite for any change in the point APIs (like JSF).
I agree, but trying to change the whole online world might take a bit longer than adding it to a framework. It would be nice if the browser itself sent a frame identifier in the request headers, then all of this would be a no brainer.
I think windowScope is a better term for this or frameScope rather than pageFlowScope because window or frame is more what it actually is.
If by "window" you are trying to correspond to a browser window, there are some interesting technical challeges -- for example, you can't assume that each window has its own cookies, so you'll need some other way for the server to tell submits apart. Ideally, one could implement this in such a way that anyone's JSF components would work transparently, but that may or may not be possible.
You wouldn't base this on cookies because it wouldn't be different in each window, you would probably have an identifier in the forms and links that would be transparent to the developer, but JSF would put a hidden form element on forms and in commandLinks and outputLinks.
Using a hidden element isn't going to help you when the user hits Crtl-N in IE, since the browser will simply clone the window contents. You have no way to differentiate between the two windows at that point.
-- Martin Cooper
In my musings on the Shale proposal (http://wiki.apache.org/struts/StrutsShale) I have been calling this sort of thing a "dialog" scope -- although "conversation" might also be a reasonable term for it. In previous threads, I've also seen this concept called "transaction scope" because it would tend to last through a "business transaction", and terminate with what amounts to a "commit" or a "rollback".
Besides multiple windows, the ADF approach appears to miss another important use case -- *nested* dialogs (I'm in the middle of one dialog but push down into a subordinate dialog to compute some result, then pop back up to pick up where I left off). Beehive (http://incubator.apache.org/beehive.html) supports this capability, and I think it's very useful.
I think this is a bit different than what is proposed here. A window/frame scope would basically attempt to make each window or frame an entirely different instance of the application. For example, a user logs in to an app, the app stores the user info to the session saying that the user is logged in. Now let's say the user clicks to view some sales information in territory T1. So T1 is saved in the window/frame scope. The user then generates a report and defines some parameters and filters for the report. Now the same user opens a new browser window and selects territory T2, so T2 is stored in a the window/frame scope for that browser window and the user goes to the same report, defines some reporting parameters and generates a second report. So now he's got two reports comparing the two territories and he can modify the report parameters in each window to make different comparisons. Without this type of scope, you either have to pass all of this info on the request like old school or make your user very unhappy since he has to redo the report for each territory for each comparison.
This is much longer than a single transaction, but shorter or equal to a session.
Travis
Further comments below.
Heath Borders wrote: +1! ADF missed a big feature, though. We should make a custom variable resolver that automatically checks the pageFlowScope Map for a variable name AFTER checking all the other scopes as required by the JSF spec. This would mean that you wouldn't have to prepend "pageFlowScope." onto all of your variable names.
This could actually be accomplished by a pluggable VariableResolver that implemented the extra check at the appropriate point. However, I would think you'd check the new "scope" after request scope, but before session scope, in order to match the expanding lifetimes of the scopes in which the search takes place.
Craig
Also the <setActionListener /> sounds handy as well. On Mon, 3 Jan 2005 00:11:37 +0100, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: Travis, I just read the article and think it is a fine concept. Also their <setActionListener/> is nice. It prevents developers from some work on creating *detail* pages, as pointed out in the article. So here is my +1 on that! Matthias -----Original Message----- From: Travis Reeder [mailto:[EMAIL PROTECTED] Sent: Sunday, January 02, 2005 11:42 PM To: MyFaces Discussion Subject: Re: New Scope It looks like the smart people over at Oracle already implemented my idea in ADF, they call it pageFlowScope: http://tinyurl.com/5jwdc Implemented almost exactly the same way I had proposed. Anyone opposed to working a new optional scope into my faces? I volunteer if everyone's ok with it because I really badly need this. Travis Stefan Langer wrote: Travis Reeder wrote: What do you guys think of this? http://www.crack3r.com/2004/12/another-scope-for-web-app-parameters.html I don't think this will work since there is no concept of a window in the http protocol. How does the server know that a new window has been opened? Unless the client tells it which currently it doesn't. So how do you decide when to create and when to destroy the window scope? I think the idea of Korhonen seems more practical although I quite don't see how to implement the deserialization behaviour in a consistent mannor without being corruptible by the client. Just my two cents Stefan -- Travis Reeder Ecommstats Web Analytics www.ecommstats.com -- Travis Reeder Ecommstats Web Analytics www.ecommstats.com
-- Travis Reeder Ecommstats Web Analytics www.ecommstats.com
-- -Heath Borders-Wing [EMAIL PROTECTED]
