Reinhard Poetz wrote:

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.


Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), but not tie the FOM to a particular Avalon object (got lots of +0's and a -1).

So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon.

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Reply via email to