Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Upayavira <uv...@odoko.co.uk>]

Jorg Heymans wrote:

<snip/>
> Also: are we carrying forward all blocks to 2.2 or is this the time
> where we ditch the obscure, rarely used and "blocks that don't really
> deserve to be a block" blocks? I'ld say we choose the 10 most often used
> and well known blocks and let the users voice their concern about those
> blocks we aren't taking forward. If enough noise, we can then still
> decide to support these blocks ourselves again or even offer it to
> dedicated users to maintain themselves.

IMO we should be aiming to have either two or three releases: bare,
small or complete.

I would prefer not to have the complete release, because I would like us
to have _a lot_ more blocks, as blocks _do_ make sense, they just don't
make sense as the core. So if we start making "complete" releases, that
complete release could start to grow into something unmanagable.

So, we identify 'core' blocks, if we haven't already. Those get included
in the 'small' build, the rest can be downloaded either via Maven or as
separate zips.

My take on core blocks is:
 * template
 * forms
 * javaflow

I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.

Regards, Upayavira

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Vadim Gritsenko <va...@reverycodes.com>]

Upayavira wrote:
> I would also ask whether we should consider replacing the serializers in
> core with those in the serializer block.

Why would you replace single class which works in 99% of cases with 4Mb of code?

Vadim

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Antonio Gallardo <ag...@agssa.net>]

Daniel Fagerstrom wrote:

> Upayavira skrev:
>
>> I would also ask whether we should consider replacing the serializers in
>> core with those in the serializer block.
>
>
> Better move the current core serializers to an own block. IMO we 
> should have a core that only contains the minimal infrastructure and 
> core apis needed for Cocoon, everything els, including sitemap 
> components should go into blocks.

Yes. can we move the current core serializer to a "deprecated" block?

Best Regards,

Antonio Gallardo.

>
> /Daniel

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Daniel Fagerstrom <da...@nada.kth.se>]

Upayavira skrev:
> Jorg Heymans wrote:
> 
> <snip/>
> 
>>Also: are we carrying forward all blocks to 2.2 or is this the time
>>where we ditch the obscure, rarely used and "blocks that don't really
>>deserve to be a block" blocks? I'ld say we choose the 10 most often used
>>and well known blocks and let the users voice their concern about those
>>blocks we aren't taking forward. If enough noise, we can then still
>>decide to support these blocks ourselves again or even offer it to
>>dedicated users to maintain themselves.
> 
> 
> IMO we should be aiming to have either two or three releases: bare,
> small or complete.
> 
> I would prefer not to have the complete release, because I would like us
> to have _a lot_ more blocks, as blocks _do_ make sense, they just don't
> make sense as the core. So if we start making "complete" releases, that
> complete release could start to grow into something unmanagable.
> 
> So, we identify 'core' blocks, if we haven't already. Those get included
> in the 'small' build, the rest can be downloaded either via Maven or as
> separate zips.
> 
> My take on core blocks is:
>  * template
>  * forms
>  * javaflow

+1

> I would also ask whether we should consider replacing the serializers in
> core with those in the serializer block.

Better move the current core serializers to an own block. IMO we should 
have a core that only contains the minimal infrastructure and core apis 
needed for Cocoon, everything els, including sitemap components should 
go into blocks.

/Daniel

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[David Crossley <cr...@apache.org>]

Jorg Heymans wrote:
> Ross Gardler wrote:
> > 
> > -1 over at Forrest one of our devs is experimenting with the Ajax block.
> > We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax
> > into the CForms block would prevent us from using it since we don't want
> > to bundle CForms for fear of confusing the boundaries between Forrest
> > (an XML publishing engine) and Cocoon (a web application framework).

Definitely keep Ajax block separate.

However i don't agree with your suggestion about never
using CForms with Forrest. The mission is broad. 

-David

> ok cool so the ajax block can be reused from other frameworks/blocks as
> well. Let's keep them separated then !
> 
> Thanks
> Jorg

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Jorg Heymans <jh...@domek.be>]

Ross Gardler wrote:
> 
> -1 over at Forrest one of our devs is experimenting with the Ajax block.
> We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax
> into the CForms block would prevent us from using it since we don't want
> to bundle CForms for fear of confusing the boundaries between Forrest
> (an XML publishing engine) and Cocoon (a web application framework).

ok cool so the ajax block can be reused from other frameworks/blocks as
well. Let's keep them separated then !


Thanks
Jorg

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Ross Gardler <rg...@apache.org>]

Jorg Heymans wrote:
> 
> Antonio Gallardo wrote:
> 
> 
>>Also, please don't forget the ajax block. It is needed by forms. ;-)
>>
> 
> 
> Is ajax really a block on it's own ? I mean i know it can be plugged
> into cforms to make forms ajax aware, but is it useable by other blocks
> as well ? I'm not really uptodate with this stuff, just curious whether
> it would make sense to move the ajax code to the cforms block. Or do we
> prefer to have separate release cycles for these two?

-1 over at Forrest one of our devs is experimenting with the Ajax block. 
We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax 
into the CForms block would prevent us from using it since we don't want 
to bundle CForms for fear of confusing the boundaries between Forrest 
(an XML publishing engine) and Cocoon (a web application framework).

Ross

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Jorg Heymans <jh...@domek.be>]

Antonio Gallardo wrote:

> Also, please don't forget the ajax block. It is needed by forms. ;-)
> 

Is ajax really a block on it's own ? I mean i know it can be plugged
into cforms to make forms ajax aware, but is it useable by other blocks
as well ? I'm not really uptodate with this stuff, just curious whether
it would make sense to move the ajax code to the cforms block. Or do we
prefer to have separate release cycles for these two?


Jorg

Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]

[Antonio Gallardo <ag...@agssa.net>]

Upayavira wrote:

>Jorg Heymans wrote:
>
><snip/>
>  
>
>>Also: are we carrying forward all blocks to 2.2 or is this the time
>>where we ditch the obscure, rarely used and "blocks that don't really
>>deserve to be a block" blocks? I'ld say we choose the 10 most often used
>>and well known blocks and let the users voice their concern about those
>>blocks we aren't taking forward. If enough noise, we can then still
>>decide to support these blocks ourselves again or even offer it to
>>dedicated users to maintain themselves.
>>    
>>
>
>IMO we should be aiming to have either two or three releases: bare,
>small or complete.
>
>I would prefer not to have the complete release, because I would like us
>to have _a lot_ more blocks, as blocks _do_ make sense, they just don't
>make sense as the core. So if we start making "complete" releases, that
>complete release could start to grow into something unmanagable.
>
>So, we identify 'core' blocks, if we haven't already. Those get included
>in the 'small' build, the rest can be downloaded either via Maven or as
>separate zips.
>
>My take on core blocks is:
> * template
> * forms
> * javaflow
>  
>
Why javaflow?
Also, please don't forget the ajax block. It is needed by forms. ;-)

>I would also ask whether we should consider replacing the serializers in
>core with those in the serializer block.
>  
>
+1

Best Regards,

Antonio Gallardo.