You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Travis Reeder <tr...@ecommstats.com> on 2004/12/29 02:14:30 UTC
New Scope
What do you guys think of this?
http://www.crack3r.com/2004/12/another-scope-for-web-app-parameters.html
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
Re: New Scope
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 03 Jan 2005 19:57:11 -0800, Travis Reeder
<tr...@ecommstats.com> wrote:
> What would it take to get a new header into the HTTP spec? ;)
That's *easy* compared to getting the browser vendors to adopt it :-).
Craig
Re: New Scope
Posted by Travis Reeder <tr...@ecommstats.com>.
What would it take to get a new header into the HTTP spec? ;)
Craig McClanahan wrote:
>On Sun, 02 Jan 2005 18:37:18 -0800, Travis Reeder
><tr...@ecommstats.com> 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 (jsr-252-comments@jcp.org) 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
>><ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
Re: New Scope
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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
>>>> <ma...@apache.org> 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
>>>>>>>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
>>>> hborders@mail.win.org
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: New Scope
Posted by Martin Cooper <ma...@apache.org>.
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
> 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
>>> <ma...@apache.org> 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
>>>>>>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
>>> hborders@mail.win.org
>>>
>>
>>
>>
>
>
>
Re: New Scope
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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.
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
>> <ma...@apache.org> 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
>>>>>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
>> hborders@mail.win.org
>>
>
>
>
Re: New Scope
Posted by Martin Cooper <ma...@apache.org>.
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
> <ma...@apache.org> 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
>>>>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
> hborders@mail.win.org
>
Re: New Scope
Posted by Heath Borders <he...@gmail.com>.
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.
On Sun, 2 Jan 2005 20:06:09 -0800 (PST), Martin Cooper
<ma...@apache.org> 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
> >>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
hborders@mail.win.org
Re: New Scope
Posted by Martin Cooper <ma...@apache.org>.
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
>>> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
>
>
Re: New Scope
Posted by Travis Reeder <tr...@ecommstats.com>.
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.
>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
>><ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
Re: New Scope
Posted by Heath Borders <he...@gmail.com>.
I was just thinking that we would first want to comply with the spec's
order, and then check our extension, so that the extension doesn't
break any applications relying on standard functionality.
However, if this was added to the spec, then yes, it makes sense to
put it after session but before request.
On Sun, 2 Jan 2005 18:56:58 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 02 Jan 2005 18:37:18 -0800, Travis Reeder
> <tr...@ecommstats.com> 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 (jsr-252-comments@jcp.org) 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
> > <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: New Scope
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 02 Jan 2005 18:37:18 -0800, Travis Reeder
<tr...@ecommstats.com> 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 (jsr-252-comments@jcp.org) 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
> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
Re: New Scope
Posted by Heath Borders <he...@gmail.com>.
How exactly are you going to track a window?
On Sun, 02 Jan 2005 18:37:18 -0800, Travis Reeder
<tr...@ecommstats.com> 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>
>
> I think windowScope is a better term for this or frameScope rather than
> pageFlowScope because window or frame is more what it actually is.
>
> Travis
>
>
> 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. Also the <setActionListener /> sounds handy as well. On Mon,
> 3 Jan 2005 00:11:37 +0100, Matthias Wessendorf
> <ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com] 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
--
-Heath Borders-Wing
hborders@mail.win.org
Re: New Scope
Posted by Travis Reeder <tr...@ecommstats.com>.
Definitely. I would also try to make it so that in faces-config.xml you
could set
<managed-bean-scope>window</managed-bean-scope>
I think windowScope is a better term for this or frameScope rather than
pageFlowScope because window or frame is more what it actually is.
Travis
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.
>
>Also the <setActionListener /> sounds handy as well.
>
>
>On Mon, 3 Jan 2005 00:11:37 +0100, Matthias Wessendorf
><ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com]
>>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
Re: New Scope
Posted by Heath Borders <he...@gmail.com>.
+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.
Also the <setActionListener /> sounds handy as well.
On Mon, 3 Jan 2005 00:11:37 +0100, Matthias Wessendorf
<ma...@matthias-wessendorf.de> 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:travis.reeder@ecommstats.com]
> 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
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
RE: New Scope
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
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:travis.reeder@ecommstats.com]
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
Re: New Scope
Posted by Travis Reeder <tr...@ecommstats.com>.
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
Re: New Scope
Posted by Stefan Langer <la...@bettsockentraeger.de>.
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