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







Reply via email to