cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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 
> 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).

> Is there anythimg more?
>
>> sitemap listeners,
>
>
>> VPCs,
>
>
> I'm waiting for community involvement.
>
> If we follow Vadim's suggestion 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111331073205551&w=2, 
> 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

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message