Sylvain Wallez wrote:
Hi all,
More and more, the limitations of objects provided by the FOM seem like arbitrary constraints that go in the way of people and produce confusion. Furthermore, these restrictions only apply to the JS flowscript and not to JavaFlow, thus making JS flowscript a second zone citizen compared to Java code.
That's why I propose to remove these restrictions my having cocoon.request, cocoon.response and cocoon.context providing the full API defined by the interfaces in org.apache.cocoon.environment.
Furthermore, I propose to add cocoon.avalonContext to provide access to the various data held by this object.
More background on this subject is available in the "Less is more... or less" discussion [1] and my answer to Jeremy's problem [2] that shows how simple it is to workaround the restricted FOM.
Please cast your votes!
- [+1] to remove restrictions on existing objects. - [?] to add cocoon.avalonContext.
I'm not sure about avalonContext.`What happens if we really drop Avalon as base framework? Do statements containing cocoon.avalonContext still work or will they be hidden (because Flowscript is interpreted) broken? If the user has to use the workaround and she recompiles the code with Cocoon 3.0 and the compiler doesn't compile her code anymore, she knows that she has a problem. Or will a possible legacy mode hide that she may have a problem?
We should really try to make moving from Cocoon 2.x to 3.x as smooth as possible and users that only use Flowscripts and the sitemap shouldn't be forced to change their applications if they want to use Cocoon in the same way as they have been used to do.
WDYT?
-- Reinhard
