Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42938085.5040700@nada.kth.se>
Date: Tue, 24 May 2005 21:29:09 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Micro kernel based Cocoon
References: <428DE86B.9020106@nada.kth.se> <428F5A4C.9090003@apache.org>
 <428F7AA4.5040901@apache.org> <4290541A.6040405@apache.org>
 <42906B19.2060101@nada.kth.se> <42906EA9.10601@apache.org>
 <42908034.7020209@apache.org> <4290F375.2090700@apache.org>
 <429190A7.6040407@nada.kth.se> <4291E70E.4070705@apache.org>
 <429314F6.2080902@nada.kth.se> <4293676B.9050908@apache.org>
In-Reply-To: <4293676B.9050908@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
> 
>> Sylvain Wallez wrote:
> 
> 
> 
>>> On that point, I proposed to write a new implementation of the 
>>> flowscript implementation. This is certainly not a total rewrite, but 
>>> a refactoring of the existing code to have an overally consistent 
>>> object model, and also introduce a "flow" object that would separate 
>>> the flow-specific operations out of the "cocoon" object that should 
>>> be the common base for the object model, and therefore be identical 
>>> in all places (flow, templates, form event listeners, etc).
>>
>> Would be nice!
>>
>> Having thought a little bit more about it I think that we, for the 
>> moment, just should make JXTG compatible with flow and independent of 
>> it. I take care of that if not anyone else feel like doing it. Then we 
>> can discuss refactorings, deprecation of confusing behaviour etc. But 
>> we need to support the behaviour of JXTG from 2.1 in 2.2 even if we 
>> hopefully can deprecate some stuff.
> 
> Agree. IIRC, we also talked to have a new CTemplate generator, which 
> could actually be the next-generation JXTG, working consistently with 
> the refactored flow engine. Both being new components could concentrate 
> on overall consistency without caring about backwards compatibility, 
> whereas the existing classes whould have to ensure this compatibility.

Exactly! We had some discussion about what CForms should contain in 
http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2. It should IMO 
also contain the converters that we discussed half a year ago 
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2.

/Daniel