cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 09:21:53 GMT

On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:

> 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).

This is more difficult to understand, but I could see why some were 

> 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.

That is fine by me.

Shall I commit the sample class you provided?
Do you have any preferences for where it should live?
Or do you have a more sophisticated way of adding this functionality, 
that you would prefer to use instead?

Thanks for your help, and thanks everyone for your votes.

regards Jeremy

View raw message