Martin Cooper wrote:
On Mon, 3 Jan 2005, Michael McGrady wrote:
Isn't this the sort of thing that Jack proposed as a JerichoState? At any rate, this seems to be something that can be managed from either session or application scope? Is this really a "scope"? Doesn't a "scope" require something which the "scope" covers, e.g. class and method in code, page, request, session and application in web servers.
If nothing ever goes away automagically, then yes, perhaps it would be better referred to as a namespace rather than a scope.
-- Martin Cooper
Basically we are, then, on the same page. I, myself, would more naturally think of the denomination as functional (view data) rather than namespace oriented. The basic idea, as I understand it, is to provide data to the view and these discussions are coupled with the clear realization throughout Java web-application-land that the web-scopes are not adequate to meet the persistent needs of the view.
Thus, I would suggest the following conceptual point of view: (A) scopes be seen as the presentation layer of view data, i.e. where pages normally get data and (B) a view data framework, application, namespace, or whatever that is outside the model data persistence layer and where the view data is persisted. The persistence of the data in the view data layer could be determined by any factor whatsoever, e.g. scope, time, model values, etc. When presented to the scopes, such data could be "abandoned", i.e. nuked in the view layer, or otherwise persisted.
I am sure that there are some bright cookies out there like Freeman, Hupfer, Gelernter and Arnold that could wrangle up a real batch of cookies with this. For my part, however, I am fairly certain that in web applications there needs to be a layer between the model and the view representing the data which manages somehow to give at least the equivalent functionality that is available between the view and the model in a standalone, true, MVC framework.
But, enough talk ---
Mike
I am just thinking that this is not really new and just needs to be done well. There must be lots of differing persistent "frameworks" out there that have held data for various applications in various time frames that are not coincident with scopes.
Mike
Martin Cooper wrote:
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 shorterI agree, but trying to change the whole online world might take a bit longer
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).
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.
You wouldn't base this on cookies because it wouldn't be different in each
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.
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 proposalI think this is a bit different than what is proposed here. A window/frame
(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.
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]
