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