Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40CEBD2B.4080603@apache.org>
Date: Tue, 15 Jun 2004 11:11:07 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Unrestricting the FOM
References: <40CD7782.1070009@apache.org> <40CEA9E3.4020909@apache.org>
In-Reply-To: <40CEA9E3.4020909@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 }