On Sun, 02 Jan 2005 18:37:18 -0800, Travis Reeder
<[EMAIL PROTECTED]> wrote:
Definitely. I would also try to make it so that in faces-config.xml you
could set
<managed-bean-scope>window</managed-bean-scope>
That kind of change would require a change to the JSF spec, however.
The JSF 1.2 spec just got published in Early Draft Review
(http://jcp.org/en/jsr/detail?id=252), so send feedback to the expert
group ([EMAIL PROTECTED]) for the kinds of things you would
like to see added.
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 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.
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.
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
