cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Micro kernel based Cocoon
Date Tue, 24 May 2005 11:50:14 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> AFAIU only some work on cForms is missing (flowscript API and 
>>>> repeater binding)
>>>
>>> That's far from the only work to do IMO, as there are a lot of 
>>> semi-finished core features. Some that come to mind: refactored 
>>> object model,
>>
>> Here the main problem is that JXTG and flow have some differences in 
>> behaviour, see 
>> http://marc2.theaimsgroup.com/?t=111648265000001&r=1&w=2 and 
>> http://marc2.theaimsgroup.com/?l=xml-cocoon-dev&m=111666682531907&w=2 
>> for description and possible solutions. We need to decide: should we 
>> keep trhe direct access of request params as properties of 
>> cocoon.request and session/context attributes as properties of 
>> cocoon.[session|context] or not. Should we support the direct usage 
>> of org.*, javax.* and com.* whithout needing the Packages. prefix in 
>> flow?
>
> 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.

<snip/>

>> As discussed in the relases thread I don't think it is realistic to 
>> stop adding features, we need a way to let rock stable core 
>> functionality coexist with new features. Otherwise the defacto "no 
>> release" policy will continue.
>
> Agree. That this "rock solid core" state that I'm currently not sure 
> about, as many changes have occured there.

I'm certainly not saying that the core in trunk is rock solid rigth now. 
What I'm saying is that when we have managed to get the core "rock 
solid" again, we should keep it that way in trunk. Marking something 
that is stable as unstable seem to be self fullfilling. People might 
become less carefull in the hope that it can be fixed later and most 
user testing and feedback dissapears.

/Daniel



Mime
View raw message