On Sun, 2 Jan 2005, Travis Reeder wrote:
Responses below:
Craig McClanahan wrote:
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.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).
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.
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.
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
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.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.
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
