cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 09:11:07 GMT
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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message