|
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. 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". 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.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. -- Travis Reeder Ecommstats Web Analytics www.ecommstats.com |
- Re: New Scope Travis Reeder
- Re: New Scope Martin Cooper
- Re: New Scope Heath Borders
- Re: New Scope Martin Cooper
- Re: New Scope Michael McGrady
- Re: New Scope Martin Cooper
- Re: New Scope Michael McGrady
- Re: New Scope Travis Reeder
- Re: New Scope Craig McClanahan

