You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by re...@apache.org on 2003/07/14 11:54:13 UTC
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_JavaScriptInterpreter.java
reinhard 2003/07/14 02:54:13
Modified: src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Log:
- changed the comment because implementation has changed
Revision Changes Path
1.2 +5 -4 cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java
Index: FOM_JavaScriptInterpreter.java
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FOM_JavaScriptInterpreter.java 8 Jul 2003 05:48:52 -0000 1.1
+++ FOM_JavaScriptInterpreter.java 14 Jul 2003 09:54:13 -0000 1.2
@@ -337,8 +337,9 @@
*
* <p>If you want to maintain the state of global variables across
* multiple invocations of <code><map:call
- * function="..."></code>, you need to invoke from the JavaScript
- * script <code>cocoon.createSession()</code>. This will place the
+ * function="..."></code>, you need to instanciate the session
+ * object which is a property of the cocoon object
+ * <code>var session = cocoon.session</code>. This will place the
* newly create Scriptable object in the user's session, where it
* will be retrieved from at the next invocation of {@link #callFunction}.</p>
*
@@ -423,12 +424,12 @@
/**
* Compile filename as JavaScript code
+ *
* @param cx Rhino context
* @param environment source resolver
* @param fileName resource uri
* @return compiled script
*/
-
public Script compileScript(Context cx,
Environment environment,
String fileName) throws Exception {
Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> I personally think that sessions should always be available from the
> flow, because I never felt the need to use flow without keeping some
> form of state but you seem to imply that your experience is different.
What is the "cost" in memory resources of every created session?
Can this be a form to get a server down?
What is the impact of autocreated session related with a DDoS attack?
I am not attacking just some question I have in my mind.
Best Regards,
Antonio Gallardo
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Christopher Oliver <re...@verizon.net>.
On second thought, the design of only creating a session only when
cocoon.session is referenced won't work. The global JavaScript scope is
saved in the session so that top-level functions called from the sitemap
using <map:call> will share global variables. This must occur whether
you reference cocoon.session or not.
Regards,
Chris
Christopher Oliver wrote:
> This is a bug in the implementation, then. Currently, it _always_
> creates a session.
>
> Geoff Howard wrote:
>
>> Pretty sure - the code is in cvs:
>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/eventcache/samples/event.js?rev=1.1&content-type=text/vnd.viewcvs-markup
>>
>>
>> But this is the whole thing:
>>
>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>
>> function cacheEvent() {
>> var cache = cocoon.getComponent(role);
>> var event = new
>> Packages.org.apache.cocoon.caching.validity.NamedEvent("one");
>> var rand = Math.random() * 10000000000000000000;
>> cache.processEvent(event);
>> cocoon.releaseComponent(cache);
>> cocoon.redirectTo("demo?pageKey=" + cocoon.request.pageKey +
>> "&rand="+rand);
>> }
>>
>> Geoff
>>
>>
>> Reinhard Pötz wrote:
>>
>>> From: Geoff Howard
>>>
>>>
>>>> Christopher Oliver wrote:
>>>>
>>>>> Yes. That is a feature of the new FOM: it always creates a
>>>>> session. The
>>>>> original API had createSession() and removeSession(). Those
>>>>
>>>>
>>>>
>>>> functions
>>>>
>>>>> were removed from FOM.
>>>>
>>>>
>>>>
>>>> I thought that was only supposed to happen after a reference to
>>>> cocoon.session, or when a continuation is created. Can someone
>>>> confirm?
>>>
>>>
>>>
>>>
>>> Yep. If there is no reference to cocoon.session no session should be
>>> created. So if you get a session if you redirectTo(uri) you
>>> discovered an error. One question: Are you sure that you haven't
>>> created a session somewhere else?
>>>
>>> Cheers,
>>> Reinhard
>>
>>
>>
>>
>
>
>
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Christopher Oliver <re...@verizon.net>.
This is a bug in the implementation, then. Currently, it _always_
creates a session.
Geoff Howard wrote:
> Pretty sure - the code is in cvs:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/eventcache/samples/event.js?rev=1.1&content-type=text/vnd.viewcvs-markup
>
>
> But this is the whole thing:
>
> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>
> function cacheEvent() {
> var cache = cocoon.getComponent(role);
> var event = new
> Packages.org.apache.cocoon.caching.validity.NamedEvent("one");
> var rand = Math.random() * 10000000000000000000;
> cache.processEvent(event);
> cocoon.releaseComponent(cache);
> cocoon.redirectTo("demo?pageKey=" + cocoon.request.pageKey +
> "&rand="+rand);
> }
>
> Geoff
>
>
> Reinhard Pötz wrote:
>
>> From: Geoff Howard
>>
>>
>>> Christopher Oliver wrote:
>>>
>>>> Yes. That is a feature of the new FOM: it always creates a session.
>>>> The
>>>> original API had createSession() and removeSession(). Those
>>>
>>>
>>> functions
>>>
>>>> were removed from FOM.
>>>
>>>
>>> I thought that was only supposed to happen after a reference to
>>> cocoon.session, or when a continuation is created. Can someone
>>> confirm?
>>
>>
>>
>> Yep. If there is no reference to cocoon.session no session should be
>> created. So if you get a session if you redirectTo(uri) you
>> discovered an error. One question: Are you sure that you haven't
>> created a session somewhere else?
>>
>> Cheers,
>> Reinhard
>
>
>
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Geoff Howard <co...@leverageweb.com>.
Pretty sure - the code is in cvs:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/eventcache/samples/event.js?rev=1.1&content-type=text/vnd.viewcvs-markup
But this is the whole thing:
var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
function cacheEvent() {
var cache = cocoon.getComponent(role);
var event = new
Packages.org.apache.cocoon.caching.validity.NamedEvent("one");
var rand = Math.random() * 10000000000000000000;
cache.processEvent(event);
cocoon.releaseComponent(cache);
cocoon.redirectTo("demo?pageKey=" + cocoon.request.pageKey +
"&rand="+rand);
}
Geoff
Reinhard Pötz wrote:
> From: Geoff Howard
>
>
>
>>Christopher Oliver wrote:
>>
>>>Yes. That is a feature of the new FOM: it always creates a session.
>>>The
>>>original API had createSession() and removeSession(). Those
>>
>>functions
>>
>>>were removed from FOM.
>>
>>I thought that was only supposed to happen after a reference to
>>cocoon.session, or when a continuation is created. Can
>>someone confirm?
>
>
> Yep. If there is no reference to cocoon.session no session should be
> created. So if you get a session if you redirectTo(uri) you
> discovered an error. One question: Are you sure that you haven't
> created a session somewhere else?
>
> Cheers,
> Reinhard
RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_JavaScriptInterpreter.java
Posted by Reinhard Pötz <re...@gmx.net>.
From: Geoff Howard
> Christopher Oliver wrote:
> > Yes. That is a feature of the new FOM: it always creates a session.
> > The
> > original API had createSession() and removeSession(). Those
> functions
> > were removed from FOM.
>
> I thought that was only supposed to happen after a reference to
> cocoon.session, or when a continuation is created. Can
> someone confirm?
Yep. If there is no reference to cocoon.session no session should be
created. So if you get a session if you redirectTo(uri) you
discovered an error. One question: Are you sure that you haven't
created a session somewhere else?
Cheers,
Reinhard
Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Jeremy Quinn dijo:
>
> On Tuesday, July 15, 2003, at 02:19 PM, Vadim Gritsenko wrote:
>
>> Christopher Oliver wrote:
>>
>>> Continuations do not require the session. But the session is needed
>>> to support cases where you use JS global variables to share data
>>> between multiple top level page flows.
>
> <snip/>
>
>> Back to Antonio's suggestion. Can we have a configuration of the flow
>> controller specifying where to store those global variables? Context,
>> session, and request (that should be analogue to "no session", right?)
>> can be possible values.
>
> I am using global variables in two situations ....
>
> 1. Static Variables
>
> stuff like could easily be in the Application or Request Context:
>
> var Beans = {
> COVERAGE : "org.iniva.archive.Coverage",
> PERSON : "org.iniva.archive.Person",
> PROJECT : "org.iniva.archive.Project",
> RESOURCE : "org.iniva.archive.Resource",
> TYPE : "org.iniva.archive.Type",
> URL : "org.iniva.archive.Url",
> USER : "org.iniva.archive.User"
> }
This type of static variables are true constants?
If this is true, then we are talking about constants and not about global
variables.
>
> 2. The User's login details
>
> this could have been handled by an authentication Action in the
> SiteMap, or even in the Container.
Yep, but this is related to the user. There are not global variables at
the high level.
>
> While I do actually use Continuations in some functions, I strenuously
> avoid keeping any other 'app state' in Global variables, so that the
> user can have multiple browser windows open with different independent
> tasks in progress in each one.
>
> If there are going to be ways of externally configuring how Global
> Variables are stored, I think we need to take into account a possible
> need to store different variable sets in different ways.
>
> I do not believe that a global setting in Cocoon.xconf would be a good
> idea though, I will have multiple FlowApps in one Cocoon Instance, they
> by no means would want to share the same settings.
I agree with you.
Thiere is one OO rule: Avoid the use of global variables.
Best Regards,
Antonio Gallardo.
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Continuations do not require the session. But the session is needed to
>> support cases where you use JS global variables to share data between
>> multiple top level page flows. In your cases, there are no shared
>> variables or else there is only a single page flow. I guess Stefano
>> and Ricardo are arguing that in almost any real application that would
>> not be the case. In Ovidiu's original design you had to explicitly
>> request use of the session in your script. Perhaps we should just turn
>> that around and require you to explicitly request to _not_ use the
>> session:
>>
>> function mySessionLessFlow() {
>> cocoon.useSession = false;
>> sendPageAndWait("blah.xml");
>> }
>>
>> What do you think?
>
> I'll repeat the question:
>
> Is it possible to use application context to share those global
> variables?
>
> What if those variables *are* global? If they are stored in the session
> they become local to the current user.
>
> Back to Antonio's suggestion. Can we have a configuration of the flow
> controller specifying where to store those global variables? Context,
> session, and request (that should be analogue to "no session", right?)
> can be possible values.
>
> Vadim
This seems to be a good solution too, as long as it's not once per
application. It seems it would need to be on <map:flow> or <map:call>?
Geoff
Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Christopher Oliver dijo:
>>> [vote] to having "request" or "context" scope.
Is this posible? As long as I know flow include a way to access the
request and context this is not part of the session.
You always need access in order to make control in MVC.
Antonio Gallardo
Re: Session user management - was Re: [flow] session creation
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Hi:
>
> There is another important request for flow. Some people ask for security
> reasons (example banking software) to allow people only login from one
> computer at once.
>
> There are 2 scenarios:
>
> 1- You are logged in computer A, in order to log in computer B you need to
> go to computer A and do a logout.
>
The nature of the web gives you IMHO little to assume about the
discipline of any user to be actively logging out (or on a
technical level: the stability of his browser/OS for that
matter)... so you'll be hitting session time-out wait periods
with the first approach?
> 2-You are logged in computer A, if you log in computer B your session in
> computer A automatically end.
>
Hm, I have to think about 'automatically end', the fact is that
the client's browser on computer A will still have his session id
and it will be used in the event of the next click...
The question is what would you want to have going on in that event?
> In order to do this we need access to some global store of open sessions
> to check if there is already a session for the given user.
>
> I understand no everybody needs this but this will be soon or later a
> request for many of us.
>
My associating mind might be way off topic here, but I couldn't
help thinking the following:
there is a number of use cases I started thinking about while
thinking wild about the generalized flow concept...
the whole idea of generalized flow almost boils down to snapping
the essence of current flow from the POV of the sitemap:
AFAICS the sitemap sees 2 types of URI's (with respect to flow)
1/ URI's that identify a 'use-case' or 'set-of-interaction-steps'
or maybe the word is even just: a 'flow' to be _started_ ...
consequence of this starting is that a URI of the second set is
made available:
2/ URI's that identify one of those dynamically created,
stateful, server side objects which are able to follow up or
_continue_ the flow (next steps in the use case)
(the sitemap also has typically different matchers for these two
kinds, and the subsequent split semantics between @function vs
@continue on the map:call seem to assert my proposition)
now, when considering access control to URI's I'ld like to make
the folowing observations:
1/ the world without continuations has left us to believe that
the control of user -> role -> access -> uri can be mapped in a
set of static ACL's
(well I might be off scale here, I just haven't ever seen
anything else applied in my experience)
2/ however the second set of URI's (the dynamic ones) disclose
the need for an access control that is oriented to
use-case-instances rather then to use-case-types...
the compelling use cases I saw where the folowing
-1- classic-session-tied: the instance is only accessible from
requests with the same session-id as the request that
instantiated the instance
-2- classic-user-tied: the instance is accessible from requests
with the same user-login (as stored in the session) --> this
would allow for the same user to continue his interaction on
computer B even if he started it on computer A (and yes, also
pick up his interaction from the same computer in the event of a
crash of his system)
-3- basic-plus-superuser-role: then the instance also becomes
accessible for any user with super-power role...
above is the use case of help-desk-assisted form fill in (which I
mentioned before): user X fills in form, needs help, calls to the
helpdesk of the company providing the service, the helpdesk clerk
steps in to continue the use case, user X just presses refresh on
the 'echo and confirm page', thx for the help and agrees by
submitting the final step
-4- basic-plus-enduser-control: the instance is accessible to the
user that created it (strategy 2) and the use case itself allows
him to add allow other users in
this last one would enable something like a chatroom
(which brings us to having locks an synchronizations in the show,
but that is another lingering wild thought)
-5- yours-here: there must be more, but can't think of any at the
moment
I do understand that all of this could be totally driven by
storing the controling meta-data for these effects in the
back-end itself
(IMHO deciding to do so however pushes these concerns up into the
business tier, where they don't necessarily belong?)
> I know we already discused it sometime ago and there was no answer to
> this. The only answer was a custom authentication subsystem.
>
missed that, any pointers to this discussion?
I'ld have to conclude also at this time that managing the access
control to the 'instance' is indeed under the realm of the use
case itself,
however, I do believe that there is a high likelyhood of having
ONE strategy for all use cases in a given application and even
that there are only a limited set of strategies
conceivable/useful when considering the set of 'all' applications
(I'm aware of the contradiction between 'limited' and 'all' but I
guess you know what I'm trying to see)
so while under control of the instance, I would find it logical
that some delegation pattern would be used.
> Best Regards,
>
> Antonio Gallardo
>
>
>
Please understand that what is above are to be considered as wild
thoughts (see Sylvain: not domesticated thoughts)
-- hoping they were not so wild that they couldn't be folowed
(just ask to clarify on specific spots)
-- there is no other goal then to feed discussion first and
hopefully ever domesticate these thoughts :-)
-- the long due future of which strategy's will be used and
maintained will depend on which itches are felt by who IMHO
-- the decission of where/how to solidify the concern in the flow
is probably subject to that long way future, however the stress
on design is that the outcome is to be available a lot earlier...
up to us to manage the incremental iterations (and refactorings)
towards the final goal
(I am nowhere near making a first draft, but hopefuly the
interaction with other ideas will get us there)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Session user management - was Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi:
There is another important request for flow. Some people ask for security
reasons (example banking software) to allow people only login from one
computer at once.
There are 2 scenarios:
1- You are logged in computer A, in order to log in computer B you need to
go to computer A and do a logout.
2-You are logged in computer A, if you log in computer B your session in
computer A automatically end.
In order to do this we need access to some global store of open sessions
to check if there is already a session for the given user.
I understand no everybody needs this but this will be soon or later a
request for many of us.
I know we already discused it sometime ago and there was no answer to
this. The only answer was a custom authentication subsystem.
Best Regards,
Antonio Gallardo
Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Vadim Gritsenko dijo:
> Christopher Oliver wrote:
>
>>>> -1 to having "request" or "context" scope.
>>>
> ...
>
>> Sorry, what I meant was that for the case you mention you don't need
>> the context. So for now I can't think of a reason why you need request
>> or context "scope".
>
>
> Actually, I've got an idea: session is not required too! :)
> Will this work?
>
> cocoon.context.myCtxAttr = "application-wide data";
> cocoon.session.myAttribute = "per user data like login ID";
> cocoon.request.myAttribute = "per request data";
>
> var myVar = "currently -- same as session attribute";
> function flow() {
> var myVar ="same as per request data";
> }
>
Yep. I think this is viable. At the end it is a kind of session. Of course
the session stuf done by the developer.
My point of view is that in order to take advantage of continuation and
control the flow, we always need some mechanism to get a "flag" back from
the user that allow us identify the user.
Another mechanism can be "store" the IP address to restrict the use of
more than once session per machine. I dont know, maybe someone can take
advantage of this getting the client IP and store it as the identity of
the user. This can work in an intranet environment, since in internet many
people connect from the same gateway computer. User computers are behind a
firewall (sometimes) and the gateway computer or a web (cache, proxy)
computer.
>
> If it works.... The only thing which *needs* to be changed is this
> automatic session creation. Should be a way to disable it.
I saw a simple example without session. When a user ask for some public
avaliable data stored in a database. If someone is using flow, then it can
first retrieve the data, verify some info on retrieved data (or make some
operations on data and at the end use a simple sendpage(). In that case we
does not need any session.
I also see the flow and continuation as a feature that can us go away from
actions.
Best Regards,
Antonio Gallardo.
>
> Vadim
RE: [flow] session creation
Posted by Reinhard Pötz <re...@gmx.net>.
Could somebody please summarize the status of this discussion and what
you propose how sessions and flows should be connected?
TIA!
Cheers,
Reinhard
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Tuesday, July 15, 2003 8:16 PM
> To: dev@cocoon.apache.org
> Subject: Re: [flow] session creation
>
>
> Christopher Oliver wrote:
>
> >>> -1 to having "request" or "context" scope.
> >>
> ...
>
> > Sorry, what I meant was that for the case you mention you don't need
> > the context. So for now I can't think of a reason why you
> need request
> > or context "scope".
>
>
> Actually, I've got an idea: session is not required too! :)
> Will this work?
>
> cocoon.context.myCtxAttr = "application-wide data";
> cocoon.session.myAttribute = "per user data like login ID";
> cocoon.request.myAttribute = "per request data";
>
> var myVar = "currently -- same as session attribute";
> function flow() {
> var myVar ="same as per request data";
> }
>
>
> If it works.... The only thing which *needs* to be changed is this
> automatic session creation. Should be a way to disable it.
>
> Vadim
>
>
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
>>> -1 to having "request" or "context" scope.
>>
...
> Sorry, what I meant was that for the case you mention you don't need
> the context. So for now I can't think of a reason why you need request
> or context "scope".
Actually, I've got an idea: session is not required too! :)
Will this work?
cocoon.context.myCtxAttr = "application-wide data";
cocoon.session.myAttribute = "per user data like login ID";
cocoon.request.myAttribute = "per request data";
var myVar = "currently -- same as session attribute";
function flow() {
var myVar ="same as per request data";
}
If it works.... The only thing which *needs* to be changed is this
automatic session creation. Should be a way to disable it.
Vadim
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Vadim Gritsenko wrote:
>
>>>
>>> I think map:flow is appropriate.
>>
>>
>>
>> +0 to turning on/off session creation in <map:flow>.
>
>
>
> Thanks.
>
>
>> -1 to having "request" or "context" scope.
>
>
>
> Any reason for this? -1 requires a reason.
>
> Vadim
>
Sorry, what I meant was that for the case you mention you don't need the
context. So for now I can't think of a reason why you need request or
context "scope".
Chris
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>> Christopher Oliver wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Is it possible to use application context to share those global
>>>> variables?
>>>
>>>
>>> It's possible, but I don't see any benefit over using the session.
>>
>>
>> Memory consumption. Several people already chimed in that they want
>> to have "session-less" flows.
>>
> I don't see how less memory will be consumed if you store it in the
> context as opposed to the session.
One session object --> at least one hashmap to store attributes, one
hashmap to store request parameters, and bunch of other stuff. One
hashmap --> at least ~100 instances of HashMap.Entry. Multiply by amount
of users and you will get into at least tens of megabytes already.
No session --> no memory occupied by it. You've got tens to might be
hundred of megabytes you can dedicate to your cache.
>>>> What if those variables *are* global? If they are stored in the
>>>> session they become local to the current user.
>>>>
>>> The intention is that they are per-user state, so storing them in
>>> the session makes sense.
>>
>>
>>
>> See example in this thread with
>> var role = .........ROLE;
>>
>> These kind of variables are not local to the current user. You can
>> also have some other application-wide variables.
>
>
> The "role" variable itself is writeable (although the value assigned
> to it was a constant). Thus, it must be per-user.
It must be per-user only if you intend to write into it. Moreover, if it
is stuff like poll results, it only harms to store it in the session --
poll results are the same results for all of the users. And I'm
specifically talking about flow using application-wide variables, not
about per-user variables. Application-wide variables are a nice addition
to the "sessionless" flow.
>>>> Back to Antonio's suggestion. Can we have a configuration of the
>>>> flow controller specifying where to store those global variables?
>>>> Context, session, and request (that should be analogue to "no
>>>> session", right?) can be possible values.
>>>
>>>
>>>
>>> Where would you specify this, exactly?
>>
>>
>>
>> Geoff suggested couple of places:
>>
>>> This seems to be a good solution too, as long as it's not once per
>>> application. It seems it would need to be on <map:flow> or <map:call>?
>>
>>
>>
>>
>> I think map:flow is appropriate.
>
>
> +0 to turning on/off session creation in <map:flow>.
Thanks.
> -1 to having "request" or "context" scope.
Any reason for this? -1 requires a reason.
Vadim
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Geoff Howard wrote:
> Christopher Oliver wrote:
>
>> Vadim Gritsenko wrote:
>
<snip>
>
>>> Geoff suggested couple of places:
>>>
>>>> This seems to be a good solution too, as long as it's not once per
>>>> application. It seems it would need to be on <map:flow> or
>>>> <map:call>?
>>>
>>>
>>> I think map:flow is appropriate.
>>
>>
>> +0 to turning on/off session creation in <map:flow>.
>>
>> -1 to having "request" or "context" scope.
>
>
> Again, this would seem fine to me. I'm not sure I totally understand
> the problem with context scope (though request I think I understand).
> What potential for abuse or error do you see?
>
> Geoff
>
If you allow modification of global variables, then multiple users would
be able to modify the same variables. If not, then you don't need any
dynamic storage at all.
Chris
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
...
>>>> What if those variables *are* global? If they are stored in the
>>>> session they become local to the current user.
>>>>
>>> The intention is that they are per-user state, so storing them in the
>>> session makes sense.
>>
>> See example in this thread with
>> var role = .........ROLE;
>>
>> These kind of variables are not local to the current user. You can
>> also have some other application-wide variables.
>
> The "role" variable itself is writeable (although the value assigned to
> it was a constant). Thus, it must be per-user.
And clearly the intent was not to have the variable change value. Is
there a better way in the current situation to access that static global
information without a session? I suppose I could pass it as a parameter
from the sitemap as a string? What is the better solution?
>>>> Back to Antonio's suggestion. Can we have a configuration of the
>>>> flow controller specifying where to store those global variables?
>>>> Context, session, and request (that should be analogue to "no
>>>> session", right?) can be possible values.
>>> Where would you specify this, exactly?
>>
>> Geoff suggested couple of places:
>>
>>> This seems to be a good solution too, as long as it's not once per
>>> application. It seems it would need to be on <map:flow> or <map:call>?
>>
>> I think map:flow is appropriate.
>
> +0 to turning on/off session creation in <map:flow>.
>
> -1 to having "request" or "context" scope.
Again, this would seem fine to me. I'm not sure I totally understand
the problem with context scope (though request I think I understand).
What potential for abuse or error do you see?
Geoff
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Is it possible to use application context to share those global
>>> variables?
>>
>>
>>
>> It's possible, but I don't see any benefit over using the session.
>
>
>
> Memory consumption. Several people already chimed in that they want to
> have "session-less" flows.
>
I don't see how less memory will be consumed if you store it in the
context as opposed to the session.
>
>>> What if those variables *are* global? If they are stored in the
>>> session they become local to the current user.
>>>
>> The intention is that they are per-user state, so storing them in the
>> session makes sense.
>
>
>
> See example in this thread with
> var role = .........ROLE;
>
> These kind of variables are not local to the current user. You can
> also have some other application-wide variables.
The "role" variable itself is writeable (although the value assigned to
it was a constant). Thus, it must be per-user.
>
>
>
>>> Back to Antonio's suggestion. Can we have a configuration of the
>>> flow controller specifying where to store those global variables?
>>> Context, session, and request (that should be analogue to "no
>>> session", right?) can be possible values.
>>
>>
>>
>> Where would you specify this, exactly?
>
>
>
> Geoff suggested couple of places:
>
>> This seems to be a good solution too, as long as it's not once per
>> application. It seems it would need to be on <map:flow> or <map:call>?
>
>
>
> I think map:flow is appropriate.
+0 to turning on/off session creation in <map:flow>.
-1 to having "request" or "context" scope.
Chris
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>> Is it possible to use application context to share those global
>> variables?
>
>
> It's possible, but I don't see any benefit over using the session.
Memory consumption. Several people already chimed in that they want to
have "session-less" flows.
>> What if those variables *are* global? If they are stored in the
>> session they become local to the current user.
>>
> The intention is that they are per-user state, so storing them in the
> session makes sense.
See example in this thread with
var role = .........ROLE;
These kind of variables are not local to the current user. You can also
have some other application-wide variables.
>> Back to Antonio's suggestion. Can we have a configuration of the flow
>> controller specifying where to store those global variables? Context,
>> session, and request (that should be analogue to "no session",
>> right?) can be possible values.
>
>
> Where would you specify this, exactly?
Geoff suggested couple of places:
> This seems to be a good solution too, as long as it's not once per
> application. It seems it would need to be on <map:flow> or <map:call>?
I think map:flow is appropriate.
Vadim
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Continuations do not require the session. But the session is needed
>> to support cases where you use JS global variables to share data
>> between multiple top level page flows. In your cases, there are no
>> shared variables or else there is only a single page flow. I guess
>> Stefano and Ricardo are arguing that in almost any real application
>> that would not be the case. In Ovidiu's original design you had to
>> explicitly request use of the session in your script. Perhaps we
>> should just turn that around and require you to explicitly request to
>> _not_ use the session:
>>
>> function mySessionLessFlow() {
>> cocoon.useSession = false;
>> sendPageAndWait("blah.xml");
>> }
>>
>> What do you think?
>
>
>
> I'll repeat the question:
>
> Is it possible to use application context to share those global
> variables?
It's possible, but I don't see any benefit over using the session.
>
> What if those variables *are* global? If they are stored in the
> session they become local to the current user.
>
The intention is that they are per-user state, so storing them in the
session makes sense.
>
> Back to Antonio's suggestion. Can we have a configuration of the flow
> controller specifying where to store those global variables? Context,
> session, and request (that should be analogue to "no session", right?)
> can be possible values.
Where would you specify this, exactly?
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Yup, I can confirm. Thank you Chris.
Geoff
Christopher Oliver wrote:
> Thanks, Geoff. This should be fixed now.
>
> Regards,
>
> Chris
>
> Geoff Howard wrote:
>
>> I can't look into this now, but wanted to report for anyone who is
>> following this discussion that it looks like the session is still
>> being created. I tried:
>>
>> global constant (created outside function, value never changed after
>> declaration)
>> local constant (created inside function, value never changed)
>>
>> with both:
>>
>> cocoon.redirectTo() and
>> cocoon.sendPage()
>>
>> If someone wants to do a sanity check, I was just using the simple
>> "uncache with flow" example from the event based cache block.
>>
>> The good news is that I'm digging into the flow implementation a
>> little and I'm getting past the "and then some magic happens" level of
>> understanding. This is really impressive stuff.
>>
>> Geoff
>>
>> Christopher Oliver wrote:
>>
>>> Geoff Howard wrote:
>>>
>>>> Thank you for this solution! Can you explain to my poor pea brain
>>>> the difference between a global variable and a global constant in
>>>> this context? IOW, if I want to use global "contants" how do I
>>>> create and access them in such a way as to avoid a session?
>>>>
>>>> Geoff
>>>
>>>
>>>
>>>
>>>
>>> If you assign a global variable outside of a function but never
>>> assign it inside a function then no session will be created, as in
>>> your earlier example, reproduced here:
>>>
>>>>
>>>>
>>>> So (can't test this now) does that mean that even currently, if
>>>> instead of:
>>>>
>>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>>> function cacheEvent() { ...
>>>>
>>>> I do:
>>>>
>>>> function cacheEvent() {
>>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>>> ...
>>>>
>>>> I skip the session?
>>>
>>>
>>>
>>> As long as you don't assign to "role" inside a function, the session
>>> will be skipped in both cases..
>>>
>>> This solution isn't perfect though. If you create a global object and
>>> modify its properties, those changes will not be preserved unless you
>>> create a session:
>>>
>>> 1 var myObj = new MyObject();
>>> 2 myObj.prop = 3;
>>> 3
>>> 4 function page1() {
>>> 5 myObj.prop = 1;
>>> 6 sendPage("page1.html");
>>> 7 }
>>> 8
>>> 9 function page2() {
>>> 10 print(myObj.prop); // prints 3 if no session, but 1 if you
>>> have a session
>>> 11 sendPage("page2.html");
>>> 12 }
>>>
>>> With no session, the assignments on lines 1-2 will be executed each
>>> time the script is called. If you have a session, they will only be
>>> executed the first time the script is called.
>>>
>>> Chris
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Thanks, Geoff. This should be fixed now.
Regards,
Chris
Geoff Howard wrote:
> I can't look into this now, but wanted to report for anyone who is
> following this discussion that it looks like the session is still
> being created. I tried:
>
> global constant (created outside function, value never changed after
> declaration)
> local constant (created inside function, value never changed)
>
> with both:
>
> cocoon.redirectTo() and
> cocoon.sendPage()
>
> If someone wants to do a sanity check, I was just using the simple
> "uncache with flow" example from the event based cache block.
>
> The good news is that I'm digging into the flow implementation a
> little and I'm getting past the "and then some magic happens" level of
> understanding. This is really impressive stuff.
>
> Geoff
>
> Christopher Oliver wrote:
>
>> Geoff Howard wrote:
>>
>>> Thank you for this solution! Can you explain to my poor pea brain
>>> the difference between a global variable and a global constant in
>>> this context? IOW, if I want to use global "contants" how do I
>>> create and access them in such a way as to avoid a session?
>>>
>>> Geoff
>>
>>
>>
>>
>> If you assign a global variable outside of a function but never
>> assign it inside a function then no session will be created, as in
>> your earlier example, reproduced here:
>>
>>>
>>>
>>> So (can't test this now) does that mean that even currently, if
>>> instead of:
>>>
>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>> function cacheEvent() { ...
>>>
>>> I do:
>>>
>>> function cacheEvent() {
>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>> ...
>>>
>>> I skip the session?
>>
>>
>> As long as you don't assign to "role" inside a function, the session
>> will be skipped in both cases..
>>
>> This solution isn't perfect though. If you create a global object and
>> modify its properties, those changes will not be preserved unless you
>> create a session:
>>
>> 1 var myObj = new MyObject();
>> 2 myObj.prop = 3;
>> 3
>> 4 function page1() {
>> 5 myObj.prop = 1;
>> 6 sendPage("page1.html");
>> 7 }
>> 8
>> 9 function page2() {
>> 10 print(myObj.prop); // prints 3 if no session, but 1 if you
>> have a session
>> 11 sendPage("page2.html");
>> 12 }
>>
>> With no session, the assignments on lines 1-2 will be executed each
>> time the script is called. If you have a session, they will only be
>> executed the first time the script is called.
>>
>> Chris
>
>
>
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
I can't look into this now, but wanted to report for anyone who is
following this discussion that it looks like the session is still being
created. I tried:
global constant (created outside function, value never changed after
declaration)
local constant (created inside function, value never changed)
with both:
cocoon.redirectTo() and
cocoon.sendPage()
If someone wants to do a sanity check, I was just using the simple
"uncache with flow" example from the event based cache block.
The good news is that I'm digging into the flow implementation a little
and I'm getting past the "and then some magic happens" level of
understanding. This is really impressive stuff.
Geoff
Christopher Oliver wrote:
> Geoff Howard wrote:
>
>> Thank you for this solution! Can you explain to my poor pea brain the
>> difference between a global variable and a global constant in this
>> context? IOW, if I want to use global "contants" how do I create and
>> access them in such a way as to avoid a session?
>>
>> Geoff
>
>
>
> If you assign a global variable outside of a function but never assign
> it inside a function then no session will be created, as in your earlier
> example, reproduced here:
>
>>
>>
>> So (can't test this now) does that mean that even currently, if
>> instead of:
>>
>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>> function cacheEvent() { ...
>>
>> I do:
>>
>> function cacheEvent() {
>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>> ...
>>
>> I skip the session?
>
> As long as you don't assign to "role" inside a function, the session
> will be skipped in both cases..
>
> This solution isn't perfect though. If you create a global object and
> modify its properties, those changes will not be preserved unless you
> create a session:
>
> 1 var myObj = new MyObject();
> 2 myObj.prop = 3;
> 3
> 4 function page1() {
> 5 myObj.prop = 1;
> 6 sendPage("page1.html");
> 7 }
> 8
> 9 function page2() {
> 10 print(myObj.prop); // prints 3 if no session, but 1 if you
> have a session
> 11 sendPage("page2.html");
> 12 }
>
> With no session, the assignments on lines 1-2 will be executed each time
> the script is called. If you have a session, they will only be executed
> the first time the script is called.
>
> Chris
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Geoff Howard wrote:
> Thank you for this solution! Can you explain to my poor pea brain the
> difference between a global variable and a global constant in this
> context? IOW, if I want to use global "contants" how do I create and
> access them in such a way as to avoid a session?
>
> Geoff
If you assign a global variable outside of a function but never assign
it inside a function then no session will be created, as in your earlier
example, reproduced here:
>
>
> So (can't test this now) does that mean that even currently, if
> instead of:
>
> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
> function cacheEvent() { ...
>
> I do:
>
> function cacheEvent() {
> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
> ...
>
> I skip the session?
As long as you don't assign to "role" inside a function, the session
will be skipped in both cases..
This solution isn't perfect though. If you create a global object and
modify its properties, those changes will not be preserved unless you
create a session:
1 var myObj = new MyObject();
2 myObj.prop = 3;
3
4 function page1() {
5 myObj.prop = 1;
6 sendPage("page1.html");
7 }
8
9 function page2() {
10 print(myObj.prop); // prints 3 if no session, but 1 if you
have a session
11 sendPage("page2.html");
12 }
With no session, the assignments on lines 1-2 will be executed each time
the script is called. If you have a session, they will only be executed
the first time the script is called.
Chris
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Thank you for this solution! Can you explain to my poor pea brain the
difference between a global variable and a global constant in this
context? IOW, if I want to use global "contants" how do I create and
access them in such a way as to avoid a session?
Geoff
Christopher Oliver wrote:
> Vadim,
>
> Your observations are correct.
>
> However, I just checked in a change to FOM_JavaScriptInterpreter that
> causes it to only create a session if you actually modify global
> variables. (Note: global constants do not cause a session to be
> created). For example, if you modify the calculator sample to not use
> global variables, i.e. like this:
>
> function calculator()
> {
> var a, b, op;
> var comp;
> a = getNumber("a");
> ...
> }
>
> instead of this:
>
> var a, b, op;
> var comp;
> function calculator()
> {
> a = getNumber("a");
> ...
> }
>
> then no session is created for it.
>
> I think this is the best solution to this problem. Do you agree?
>
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim,
>
> Your observations are correct.
>
> However, I just checked in a change to FOM_JavaScriptInterpreter that
> causes it to only create a session if you actually modify global
> variables. (Note: global constants do not cause a session to be
> created). For example, if you modify the calculator sample to not use
> global variables, i.e. like this:
...
> then no session is created for it.
>
> I think this is the best solution to this problem. Do you agree?
Yes! Thanks much
Vadim
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Vadim,
Your observations are correct.
However, I just checked in a change to FOM_JavaScriptInterpreter that
causes it to only create a session if you actually modify global
variables. (Note: global constants do not cause a session to be
created). For example, if you modify the calculator sample to not use
global variables, i.e. like this:
function calculator()
{
var a, b, op;
var comp;
a = getNumber("a");
...
}
instead of this:
var a, b, op;
var comp;
function calculator()
{
a = getNumber("a");
...
}
then no session is created for it.
I think this is the best solution to this problem. Do you agree?
Regards,
Chris
Vadim Gritsenko wrote:
> Jeremy Quinn wrote:
>
>> I am using global variables in two situations ....
>>
>> 1. Static Variables
>>
>> stuff like could easily be in the Application or Request Context:
>
>
>
> I found out in Cocoon.idl (is it up to date?) that (IIUC) you have
> access already to cocoon.context. So you write something like:
>
> cocoon.context.Beans =
>
>> {
>> COVERAGE : "org.iniva.archive.Coverage",
>> PERSON : "org.iniva.archive.Person",
>> PROJECT : "org.iniva.archive.Project",
>> RESOURCE : "org.iniva.archive.Resource",
>> TYPE : "org.iniva.archive.Type",
>> URL : "org.iniva.archive.Url",
>> USER : "org.iniva.archive.User"
>> }
>
>
>
> (Beans will be context attribute). This should provide fallback in
> case flow context variables get rejected (Christopher already -1'd it).
>
>
>> If there are going to be ways of externally configuring how Global
>> Variables are stored, I think we need to take into account a possible
>> need to store different variable sets in different ways.
>
>
>
> That would be terrific.
>
>
>> I do not believe that a global setting in Cocoon.xconf would be a
>> good idea though, I will have multiple FlowApps in one Cocoon
>> Instance, they by no means would want to share the same settings.
>
>
>
> Agreed, cocoon.xconf is not a good place.
>
> Vadim
>
>
>
Re: [flow] session creation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, July 15, 2003, at 06:35 PM, Vadim Gritsenko wrote:
> Jeremy Quinn wrote:
>
>> I am using global variables in two situations ....
>>
>> 1. Static Variables
>>
>> stuff like could easily be in the Application or Request Context:
>
>
> I found out in Cocoon.idl (is it up to date?) that (IIUC) you have
> access already to cocoon.context. So you write something like:
>
> cocoon.context.Beans =
Great tip!!
>
>> {
>> COVERAGE : "org.iniva.archive.Coverage",
>> PERSON : "org.iniva.archive.Person",
>> PROJECT : "org.iniva.archive.Project",
>> RESOURCE : "org.iniva.archive.Resource",
>> TYPE : "org.iniva.archive.Type",
>> URL : "org.iniva.archive.Url",
>> USER : "org.iniva.archive.User"
>> }
>
>
> (Beans will be context attribute). This should provide fallback in
> case flow context variables get rejected (Christopher already -1'd > it).
>
>
>> If there are going to be ways of externally configuring how Global
>> Variables are stored, I think we need to take into account a possible
>> need to store different variable sets in different ways.
>
>
> That would be terrific.
But considering the above tip, is this not FS now?
regards Jeremy
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeremy Quinn wrote:
> I am using global variables in two situations ....
>
> 1. Static Variables
>
> stuff like could easily be in the Application or Request Context:
I found out in Cocoon.idl (is it up to date?) that (IIUC) you have
access already to cocoon.context. So you write something like:
cocoon.context.Beans =
> {
> COVERAGE : "org.iniva.archive.Coverage",
> PERSON : "org.iniva.archive.Person",
> PROJECT : "org.iniva.archive.Project",
> RESOURCE : "org.iniva.archive.Resource",
> TYPE : "org.iniva.archive.Type",
> URL : "org.iniva.archive.Url",
> USER : "org.iniva.archive.User"
> }
(Beans will be context attribute). This should provide fallback in case
flow context variables get rejected (Christopher already -1'd it).
> If there are going to be ways of externally configuring how Global
> Variables are stored, I think we need to take into account a possible
> need to store different variable sets in different ways.
That would be terrific.
> I do not believe that a global setting in Cocoon.xconf would be a good
> idea though, I will have multiple FlowApps in one Cocoon Instance,
> they by no means would want to share the same settings.
Agreed, cocoon.xconf is not a good place.
Vadim
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Jeremy Quinn wrote:
...
> In the Petstore app, it makes sense to only allow one instance of the
> store per user, so if they open another window they are still editing
> the same store. So in your case it makes sense to have the petstore as a
> global (HTTP Session) variable.
>
> In my application, I want people to be able to work on different parts
> of the application at the same time, independently of each other. In one
> window they may be working on 'Coverage' in another window they may be
> working on 'People', this is a design decision. Therefore in my case I
> must not keep 'the thing being edited' in a global variable. My
> externally invoked functions therefore always take an ID and TYPE
> parameter, so that this specific object can be retrieved for each
> function call. It is only when I have a Continuation that the specific
> Object is held in a variable, and then it is always a local one.
>
> Conversely, the logged in User object must be shared by all invocations,
> so this is a global.
Could this still be accomplished in the global session with separate
continuation id's? The data is still stored in the same session but
under different keys and would not then intermingle?
Geoff
Re: [flow] session creation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, July 15, 2003, at 05:43 PM, Christopher Oliver wrote:
> Jeremy Quinn wrote:
>
>>
>> On Tuesday, July 15, 2003, at 02:19 PM, Vadim Gritsenko wrote:
>>
<snip/>
>>
>> While I do actually use Continuations in some functions, I
>> strenuously avoid keeping any other 'app state' in Global variables,
>> so that the user can have multiple browser windows open with
>> different independent tasks in progress in each one.
>
> Not sure what you mean here. Using JS global variables makes it very
> easy to share state between page flows, for example in the Petstore
> the same Cart object is shared between various page flows:
>
> - addToCart
> - removeItemFromCart
> - updateCart
> - showCart
> - checkout
In the Petstore app, it makes sense to only allow one instance of the
store per user, so if they open another window they are still editing
the same store. So in your case it makes sense to have the petstore as
a global (HTTP Session) variable.
In my application, I want people to be able to work on different parts
of the application at the same time, independently of each other. In
one window they may be working on 'Coverage' in another window they may
be working on 'People', this is a design decision. Therefore in my case
I must not keep 'the thing being edited' in a global variable. My
externally invoked functions therefore always take an ID and TYPE
parameter, so that this specific object can be retrieved for each
function call. It is only when I have a Continuation that the specific
Object is held in a variable, and then it is always a local one.
Conversely, the logged in User object must be shared by all
invocations, so this is a global.
Hope this is clearer.
regards Jeremy
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Jeremy Quinn wrote:
>
> On Tuesday, July 15, 2003, at 02:19 PM, Vadim Gritsenko wrote:
>
>> Christopher Oliver wrote:
>>
>>> Continuations do not require the session. But the session is needed
>>> to support cases where you use JS global variables to share data
>>> between multiple top level page flows.
>>
>
> <snip/>
>
>> Back to Antonio's suggestion. Can we have a configuration of the flow
>> controller specifying where to store those global variables? Context,
>> session, and request (that should be analogue to "no session",
>> right?) can be possible values.
>
>
> I am using global variables in two situations ....
>
> 1. Static Variables
>
> stuff like could easily be in the Application or Request Context:
>
> var Beans = {
> COVERAGE : "org.iniva.archive.Coverage",
> PERSON : "org.iniva.archive.Person",
> PROJECT : "org.iniva.archive.Project",
> RESOURCE : "org.iniva.archive.Resource",
> TYPE : "org.iniva.archive.Type",
> URL : "org.iniva.archive.Url",
> USER : "org.iniva.archive.User"
> }
There's no need to store this elsewhere. It's already "stored" in your
script.
>
>
> 2. The User's login details
>
> this could have been handled by an authentication Action in the
> SiteMap, or even in the Container.
>
> While I do actually use Continuations in some functions, I strenuously
> avoid keeping any other 'app state' in Global variables, so that the
> user can have multiple browser windows open with different independent
> tasks in progress in each one.
Not sure what you mean here. Using JS global variables makes it very
easy to share state between page flows, for example in the Petstore the
same Cart object is shared between various page flows:
- addToCart
- removeItemFromCart
- updateCart
- showCart
- checkout
Chris
Re: [flow] session creation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, July 15, 2003, at 02:19 PM, Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Continuations do not require the session. But the session is needed
>> to support cases where you use JS global variables to share data
>> between multiple top level page flows.
<snip/>
> Back to Antonio's suggestion. Can we have a configuration of the flow
> controller specifying where to store those global variables? Context,
> session, and request (that should be analogue to "no session", right?)
> can be possible values.
I am using global variables in two situations ....
1. Static Variables
stuff like could easily be in the Application or Request Context:
var Beans = {
COVERAGE : "org.iniva.archive.Coverage",
PERSON : "org.iniva.archive.Person",
PROJECT : "org.iniva.archive.Project",
RESOURCE : "org.iniva.archive.Resource",
TYPE : "org.iniva.archive.Type",
URL : "org.iniva.archive.Url",
USER : "org.iniva.archive.User"
}
2. The User's login details
this could have been handled by an authentication Action in the
SiteMap, or even in the Container.
While I do actually use Continuations in some functions, I strenuously
avoid keeping any other 'app state' in Global variables, so that the
user can have multiple browser windows open with different independent
tasks in progress in each one.
If there are going to be ways of externally configuring how Global
Variables are stored, I think we need to take into account a possible
need to store different variable sets in different ways.
I do not believe that a global setting in Cocoon.xconf would be a good
idea though, I will have multiple FlowApps in one Cocoon Instance, they
by no means would want to share the same settings.
regards Jeremy
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Continuations do not require the session. But the session is needed to
> support cases where you use JS global variables to share data between
> multiple top level page flows. In your cases, there are no shared
> variables or else there is only a single page flow. I guess Stefano
> and Ricardo are arguing that in almost any real application that would
> not be the case. In Ovidiu's original design you had to explicitly
> request use of the session in your script. Perhaps we should just turn
> that around and require you to explicitly request to _not_ use the
> session:
>
> function mySessionLessFlow() {
> cocoon.useSession = false;
> sendPageAndWait("blah.xml");
> }
>
> What do you think?
I'll repeat the question:
Is it possible to use application context to share those global
variables?
What if those variables *are* global? If they are stored in the session
they become local to the current user.
Back to Antonio's suggestion. Can we have a configuration of the flow
controller specifying where to store those global variables? Context,
session, and request (that should be analogue to "no session", right?)
can be possible values.
Vadim
Re: [flow] session creation
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Christopher Oliver dijo:
> Continuations do not require the session. But the session is needed to
> support cases where you use JS global variables to share data between
> multiple top level page flows. In your cases, there are no shared
> variables or else there is only a single page flow. I guess Stefano and
> Ricardo are arguing that in almost any real application that would not
> be the case. In Ovidiu's original design you had to explicitly request
> use of the session in your script. Perhaps we should just turn that
> around and require you to explicitly request to _not_ use the session:
>
> function mySessionLessFlow() {
> cocoon.useSession = false;
> sendPageAndWait("blah.xml");
> }
>
> What do you think?
Would be better create a config variable (cocoon.xconf or sitemap.xmap)
that allow user to turn on (or off) the use (by default) the session
tracking?
In some application the use of sessions is a must then we can configure by
default to use session. In other application the session are not too
important or less used and we can off the sessions by default.
Also your proposed turn on (or off) can be allowed to do into a function.
Would this be better? Of course session on must be the default.
Best Regards,
Antonio Gallardo
>
> Regards,
>
> Chris
>
> Geoff Howard wrote:
>
>> Upayavira wrote:
>>
>>>> I personally think that sessions should always be available from the
>>>> flow, because I never felt the need to use flow without keeping
>>>> some form of state but you seem to imply that your experience is
>>>> different.
>>>>
>>>> Can you show us how?
>>>
>>>
>>>
>>> I have a simple site where I'm using flow (for the first time). It is
>>> a single page site, with a form that the user can submit to change
>>> the info
>>> presented on the page. The page uses SendPage(), and doesn't use
>>> continuations, as all of the 'global' data is passed back and forward
>>> via
>>> a form on the page itself. So no global variables are needed.
>>> As no global variables are needed, no session is needed.
>>>
>>> It's a pretty trivial example, but to my mind it is a site that uses
>>> flow
>>> but doesn't need sessions. Or am I doing something wrong ;-)
>>>
>>> Regards, Upayavira
>>
>>
>> I don't think I can add much to that - the trivial examples are the
>> important ones in this case. The actual script I was working on at
>> the time is the one in the eventcache block (which by the way is a
>> confusing name - it's about uncaching with events). I posted it in
>> this thread, but stripping it to the bones, it's just:
>>
>> function func() {
>> doSomeThing();
>> sendPage(uri); _or_ redirectTo(uri)
>> }
>>
>> No continuations in a perfect world should mean no session. Don't
>> know nearly enough about the FOM implementation that Chris did (but I
>> think it involves vodoo somewhere ;) ) to suggest whether that's
>> technically feasible.
>>
>> Geoff
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Geoff Howard wrote:
> Christopher Oliver wrote:
>
>> Geoff Howard wrote:
>>
>>> Christopher Oliver wrote:
>>>
>>>> Continuations do not require the session. But the session is needed
>>>> to support cases where you use JS global variables to share data
>>>> between multiple top level page flows. In your cases, there are no
>>>> shared variables or else there is only a single page flow.
>>>
>>>
>>>
>>>
>>> So (can't test this now) does that mean that even currently, if
>>> instead of:
>>>
>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>> function cacheEvent() { ...
>>>
>>> I do:
>>>
>>> function cacheEvent() {
>>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>>> ...
>>>
>>> I skip the session?
>>
>>
>>
>> Either would work without the session. Each time your script is
>> executed the "role" global variable will be reset to
>> "Packages.org.apache.cocoon.caching.Cache.ROLE".
>>
>
> Right, but what I was asking was "does the session not get
> automagically created with the current code if I do the second?"
Currently the session is created regardless of what you do.
>
> Geoff
>
>
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Christopher Oliver wrote:
> Geoff Howard wrote:
>
>> Christopher Oliver wrote:
>>
>>> Continuations do not require the session. But the session is needed
>>> to support cases where you use JS global variables to share data
>>> between multiple top level page flows. In your cases, there are no
>>> shared variables or else there is only a single page flow.
>>
>>
>>
>> So (can't test this now) does that mean that even currently, if
>> instead of:
>>
>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>> function cacheEvent() { ...
>>
>> I do:
>>
>> function cacheEvent() {
>> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
>> ...
>>
>> I skip the session?
>
>
> Either would work without the session. Each time your script is executed
> the "role" global variable will be reset to
> "Packages.org.apache.cocoon.caching.Cache.ROLE".
>
Right, but what I was asking was "does the session not get automagically
created with the current code if I do the second?"
Geoff
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Geoff Howard wrote:
> Christopher Oliver wrote:
>
>> Continuations do not require the session. But the session is needed
>> to support cases where you use JS global variables to share data
>> between multiple top level page flows. In your cases, there are no
>> shared variables or else there is only a single page flow.
>
>
> So (can't test this now) does that mean that even currently, if
> instead of:
>
> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
> function cacheEvent() { ...
>
> I do:
>
> function cacheEvent() {
> var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
> ...
>
> I skip the session?
Either would work without the session. Each time your script is executed
the "role" global variable will be reset to
"Packages.org.apache.cocoon.caching.Cache.ROLE".
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Christopher Oliver wrote:
> Continuations do not require the session. But the session is needed to
> support cases where you use JS global variables to share data between
> multiple top level page flows. In your cases, there are no shared
> variables or else there is only a single page flow.
So (can't test this now) does that mean that even currently, if instead of:
var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
function cacheEvent() { ...
I do:
function cacheEvent() {
var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
...
I skip the session?
> I guess Stefano and
> Ricardo are arguing that in almost any real application that would not
> be the case.
And I totally agree, with the slight modification that not all flows in
a real application will need to share global variables across multiple
top level page flows.
> In Ovidiu's original design you had to explicitly request
> use of the session in your script. Perhaps we should just turn that
> around and require you to explicitly request to _not_ use the session:
>
> function mySessionLessFlow() {
> cocoon.useSession = false;
> sendPageAndWait("blah.xml");
> }
>
> What do you think?
I think this would work well. In this case it is the burden of the flow
writer to explicitly claim that they don't need state.
I am not heavily into it yet, but I am starting to go through an
application I wrote (in a frozen version of 2.1 dev) and upgrade to 2.1
beta/whatever and abolish all actions in favor of flow, and I am fairly
confident that I'll be able to come up with some more useful cases that
justify this. If there's strong feeling to the contrary though, I'd
also be fine waiting to add this until I can prove it.
Geoff
> Geoff Howard wrote:
>
>> Upayavira wrote:
>>
>>>> I personally think that sessions should always be available from the
>>>> flow, because I never felt the need to use flow without keeping some
>>>> form of state but you seem to imply that your experience is different.
>>>>
>>>> Can you show us how?
>>>
>>>
>>>
>>>
>>> I have a simple site where I'm using flow (for the first time). It is a
>>> single page site, with a form that the user can submit to change the
>>> info
>>> presented on the page. The page uses SendPage(), and doesn't use
>>> continuations, as all of the 'global' data is passed back and forward
>>> via
>>> a form on the page itself. So no global variables are needed.
>>> As no global variables are needed, no session is needed.
>>>
>>> It's a pretty trivial example, but to my mind it is a site that uses
>>> flow
>>> but doesn't need sessions. Or am I doing something wrong ;-)
>>>
>>> Regards, Upayavira
>>
>>
>>
>> I don't think I can add much to that - the trivial examples are the
>> important ones in this case. The actual script I was working on at
>> the time is the one in the eventcache block (which by the way is a
>> confusing name - it's about uncaching with events). I posted it in
>> this thread, but stripping it to the bones, it's just:
>>
>> function func() {
>> doSomeThing();
>> sendPage(uri); _or_ redirectTo(uri)
>> }
>>
>> No continuations in a perfect world should mean no session. Don't
>> know nearly enough about the FOM implementation that Chris did (but I
>> think it involves vodoo somewhere ;) ) to suggest whether that's
>> technically feasible.
>>
>> Geoff
Re: [flow] session creation
Posted by Christopher Oliver <re...@verizon.net>.
Continuations do not require the session. But the session is needed to
support cases where you use JS global variables to share data between
multiple top level page flows. In your cases, there are no shared
variables or else there is only a single page flow. I guess Stefano and
Ricardo are arguing that in almost any real application that would not
be the case. In Ovidiu's original design you had to explicitly request
use of the session in your script. Perhaps we should just turn that
around and require you to explicitly request to _not_ use the session:
function mySessionLessFlow() {
cocoon.useSession = false;
sendPageAndWait("blah.xml");
}
What do you think?
Regards,
Chris
Geoff Howard wrote:
> Upayavira wrote:
>
>>> I personally think that sessions should always be available from the
>>> flow, because I never felt the need to use flow without keeping some
>>> form of state but you seem to imply that your experience is different.
>>>
>>> Can you show us how?
>>
>>
>>
>> I have a simple site where I'm using flow (for the first time). It is a
>> single page site, with a form that the user can submit to change the
>> info
>> presented on the page. The page uses SendPage(), and doesn't use
>> continuations, as all of the 'global' data is passed back and forward
>> via
>> a form on the page itself. So no global variables are needed.
>> As no global variables are needed, no session is needed.
>>
>> It's a pretty trivial example, but to my mind it is a site that uses
>> flow
>> but doesn't need sessions. Or am I doing something wrong ;-)
>>
>> Regards, Upayavira
>
>
> I don't think I can add much to that - the trivial examples are the
> important ones in this case. The actual script I was working on at
> the time is the one in the eventcache block (which by the way is a
> confusing name - it's about uncaching with events). I posted it in
> this thread, but stripping it to the bones, it's just:
>
> function func() {
> doSomeThing();
> sendPage(uri); _or_ redirectTo(uri)
> }
>
> No continuations in a perfect world should mean no session. Don't
> know nearly enough about the FOM implementation that Chris did (but I
> think it involves vodoo somewhere ;) ) to suggest whether that's
> technically feasible.
>
> Geoff
>
>
Re: [flow] session creation
Posted by Geoff Howard <co...@leverageweb.com>.
Upayavira wrote:
>>I personally think that sessions should always be available from the
>>flow, because I never felt the need to use flow without keeping some
>>form of state but you seem to imply that your experience is different.
>>
>>Can you show us how?
>
>
> I have a simple site where I'm using flow (for the first time). It is a
> single page site, with a form that the user can submit to change the info
> presented on the page. The page uses SendPage(), and doesn't use
> continuations, as all of the 'global' data is passed back and forward via
> a form on the page itself. So no global variables are needed.
>
> As no global variables are needed, no session is needed.
>
> It's a pretty trivial example, but to my mind it is a site that uses flow
> but doesn't need sessions. Or am I doing something wrong ;-)
>
> Regards, Upayavira
I don't think I can add much to that - the trivial examples are the
important ones in this case. The actual script I was working on at the
time is the one in the eventcache block (which by the way is a confusing
name - it's about uncaching with events). I posted it in this thread,
but stripping it to the bones, it's just:
function func() {
doSomeThing();
sendPage(uri); _or_ redirectTo(uri)
}
No continuations in a perfect world should mean no session. Don't know
nearly enough about the FOM implementation that Chris did (but I think
it involves vodoo somewhere ;) ) to suggest whether that's technically
feasible.
Geoff
Re: [flow] session creation
Posted by Upayavira <uv...@upaya.co.uk>.
> I personally think that sessions should always be available from the
> flow, because I never felt the need to use flow without keeping some
> form of state but you seem to imply that your experience is different.
>
> Can you show us how?
I have a simple site where I'm using flow (for the first time). It is a
single page site, with a form that the user can submit to change the info
presented on the page. The page uses SendPage(), and doesn't use
continuations, as all of the 'global' data is passed back and forward via
a form on the page itself. So no global variables are needed.
As no global variables are needed, no session is needed.
It's a pretty trivial example, but to my mind it is a site that uses flow
but doesn't need sessions. Or am I doing something wrong ;-)
Regards, Upayavira
Re: [flow] session creation
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On Monday, Jul 14, 2003, at 11:20 America/Guayaquil, Geoff Howard wrote:
>
>> Christopher Oliver wrote:
>>
>>> Yes. That is a feature of the new FOM: it always creates a session.
>>> The original API had createSession() and removeSession(). Those
>>> functions were removed from FOM.
>>
Can flow store its global variables not in automatically created session
but in the application context? If not, how hard it will be to implement?
Vadim
[flow] session creation
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Jul 14, 2003, at 11:20 America/Guayaquil, Geoff Howard wrote:
> Christopher Oliver wrote:
>> Yes. That is a feature of the new FOM: it always creates a session.
>> The original API had createSession() and removeSession(). Those
>> functions were removed from FOM.
>
> I thought that was only supposed to happen after a reference to
> cocoon.session, or when a continuation is created. Can someone
> confirm?
>
I think we didn't reach consensus on that, there were still different
positions on the table.
I personally think that sessions should always be available from the
flow, because I never felt the need to use flow without keeping some
form of state but you seem to imply that your experience is different.
Can you show us how?
--
Stefano
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Geoff Howard <co...@leverageweb.com>.
Christopher Oliver wrote:
> Yes. That is a feature of the new FOM: it always creates a session. The
> original API had createSession() and removeSession(). Those functions
> were removed from FOM.
I thought that was only supposed to happen after a reference to
cocoon.session, or when a continuation is created. Can someone confirm?
Geoff
> Geoff Howard wrote:
>
>> Speaking of session handling in flow, (I think) I noticed last night
>> that doing a redirectTo(uri) appears to (sometimes?) create a session.
>>
>> At least, I was getting a jsessionid; in the urls in testing out the
>> sample I put in the eventcache block.
>>
>> Is that correct behavior? In that case, I was doing very stateless
>> flow, and didn't really want sessions created.
>>
>> Geoff
>>
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Christopher Oliver <re...@verizon.net>.
Yes. That is a feature of the new FOM: it always creates a session. The
original API had createSession() and removeSession(). Those functions
were removed from FOM.
Chris
Geoff Howard wrote:
> Speaking of session handling in flow, (I think) I noticed last night
> that doing a redirectTo(uri) appears to (sometimes?) create a session.
>
> At least, I was getting a jsessionid; in the urls in testing out the
> sample I put in the eventcache block.
>
> Is that correct behavior? In that case, I was doing very stateless
> flow, and didn't really want sessions created.
>
> Geoff
>
> reinhard@apache.org wrote:
>
>> reinhard 2003/07/14 02:54:13
>>
>> Modified: src/java/org/apache/cocoon/components/flow/javascript/fom
>> FOM_JavaScriptInterpreter.java
>> Log:
>> - changed the comment because implementation has changed
>> Revision Changes Path
>> 1.2 +5 -4
>> cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java
>>
>> Index: FOM_JavaScriptInterpreter.java
>> ===================================================================
>> RCS file:
>> /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java,v
>>
>> retrieving revision 1.1
>> retrieving revision 1.2
>> diff -u -r1.1 -r1.2
>> --- FOM_JavaScriptInterpreter.java 8 Jul 2003 05:48:52 -0000 1.1
>> +++ FOM_JavaScriptInterpreter.java 14 Jul 2003 09:54:13 -0000
>> 1.2
>> @@ -337,8 +337,9 @@
>> *
>> * <p>If you want to maintain the state of global variables
>> across
>> * multiple invocations of <code><map:call
>> - * function="..."></code>, you need to invoke from the
>> JavaScript
>> - * script <code>cocoon.createSession()</code>. This will place
>> the
>> + * function="..."></code>, you need to instanciate the session
>> + * object which is a property of the cocoon object + *
>> <code>var session = cocoon.session</code>. This will place the
>> * newly create Scriptable object in the user's session, where it
>> * will be retrieved from at the next invocation of {@link
>> #callFunction}.</p>
>> *
>
>
>
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Posted by Geoff Howard <co...@leverageweb.com>.
Speaking of session handling in flow, (I think) I noticed last night
that doing a redirectTo(uri) appears to (sometimes?) create a session.
At least, I was getting a jsessionid; in the urls in testing out the
sample I put in the eventcache block.
Is that correct behavior? In that case, I was doing very stateless
flow, and didn't really want sessions created.
Geoff
reinhard@apache.org wrote:
> reinhard 2003/07/14 02:54:13
>
> Modified: src/java/org/apache/cocoon/components/flow/javascript/fom
> FOM_JavaScriptInterpreter.java
> Log:
> - changed the comment because implementation has changed
>
> Revision Changes Path
> 1.2 +5 -4 cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java
>
> Index: FOM_JavaScriptInterpreter.java
> ===================================================================
> RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- FOM_JavaScriptInterpreter.java 8 Jul 2003 05:48:52 -0000 1.1
> +++ FOM_JavaScriptInterpreter.java 14 Jul 2003 09:54:13 -0000 1.2
> @@ -337,8 +337,9 @@
> *
> * <p>If you want to maintain the state of global variables across
> * multiple invocations of <code><map:call
> - * function="..."></code>, you need to invoke from the JavaScript
> - * script <code>cocoon.createSession()</code>. This will place the
> + * function="..."></code>, you need to instanciate the session
> + * object which is a property of the cocoon object
> + * <code>var session = cocoon.session</code>. This will place the
> * newly create Scriptable object in the user's session, where it
> * will be retrieved from at the next invocation of {@link #callFunction}.</p>
> *