Daniel Fagerstrom wrote:<snip/>
Somewhat OT, but I really do't think we should do any work on the original JXTG. It's better to remove it and focus on the refactored one. Even if we not have finished the refactoring of the internal APIs, that's no reason for keeping the original one.
What's left to do for switching to the refactored one is to make the environment handling back compatible. The environment in the refactored is built above o.a.c.environment.TemplateObjectModelHelper while the original is built on o.a.c.components.flow.javascript.fom.FOM_Cocoon. What needs to be done is basically to embed the Request object in the TemplateObjectModelHelper with a FOM_Request from FOM_Cocoon etc.
We should definately do something about the enviroment handling in general in Cocoon, with Acessors or something similar, but for the time being we should get rid of the original JXTG so no one feel tempted to start parallel development on it.
We could already do it in 2.2. I think there are so many samples out there that there will be not much work tracking the incompatibilities.
I added the FOM wrappers in the TemplateObjectModelHelper. It breaks two test cases that uses #{$cocoon/request/protocol}, but these doesn't work in the original JXTG either.
Now the question is if this is the correct behaviour, according to the documentation http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#Expression+Languages, it seem like the get methods in the request object should be accessible as properties. In the refactored FOM_Cocoon in AttributeHolderJavaObject.get (super class of FOM_Request etc), the property access is explicitely turned of for methods. The old FOM_Cocoon code before the refactoring behaved in the same way IIUC. Is the documentation wrong?, has it been all the time?
I didn't add the request etc properties whithout Cocoon prefix, as these according to the documentation has been deprecated for ever. And as we have the same behaviour for flow and non flow use of the refactored JXTG they are not needed any more. They are of course easy to add if anyone find them important.
/Daniel
