cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Micro kernel based Cocoon
Date Mon, 23 May 2005 14:22:06 GMT
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 
> and 
> 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).

> Is there anythimg more?
>> sitemap listeners,
>> VPCs,
> I'm waiting for community involvement.
> If we follow Vadim's suggestion 
> nothing in core need to depend on vpc code and the vpc code could be 
> mocĀ“ved to an own (unstable) block.

Sounds good.

>> third-party containers, etc. Not that these features don't work, but 
>> they lack (at least that's my impression) some more use cases and 
>> demos to be strong enough for a stable release.
>> Sure, we can make an alpha release to give people a sign that we are 
>> doing some progress, but this should be for us the sign that no more 
>> features should be added in that branch.
> 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.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message