cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 07:48:51 GMT
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.



View raw message