You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <gi...@apache.org> on 2004/03/30 10:22:45 UTC

Unstable stuff (was: Re: [VOTE] Move javaflow into scratchpad)

Bertrand Delacretaz wrote:

> Le 30 mars 04, à 09:45, Gianugo Rabellino a écrit :
> 
>> ...(though what I'd really like to see is a more clean separation of 
>> stable/unstable blocks, possibly with a clear directory hierarchy 
>> (src/blocks/stable, src/blocks/unstable), a default commented out 
>> unstable.blocks.properties that Joe User *has* to read to compile such 
>> stuff and some more warning around...
> 
> 
> Maybe just naming the block "scratchpad-javaflow" would do?
> 
> This would avoid the mess of adding yet more stuff to the current 
> scratchpad block, yet make it very clear what's going on.

Well, actually my point is about user awareness. Today you just download 
Cocoon, read the docs, type ./build.sh and see some fast-scrolling 
messages muttering about unstable stuff, and that's it. I'm thinking of 
something more specific that forces the user to know what she's doing. A 
different property/target (./build.sh -Dinclude.unstable=true)? A 
different file to edit (local.unstable.block.properties)? Everything 
would do: but clearly a message that scrolls during the build is not enough.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)

Re: Unstable stuff

Posted by Ugo Cei <u....@cbim.it>.
Torsten Curdt wrote:
>> Well, actually my point is about user awareness. Today you just 
>> download Cocoon, read the docs, type ./build.sh and see some 
>> fast-scrolling messages muttering about unstable stuff, and that's it. 
>> I'm thinking of something more specific that forces the user to know 
>> what she's doing. A different property/target (./build.sh 
>> -Dinclude.unstable=true)? A different file to edit 
>> (local.unstable.block.properties)? Everything would do: but clearly a 
>> message that scrolls during the build is not enough.
> 
> 
> Well, having it disabled by default is a clear sign?

If we disable by default unstable blocks, first-time users won't even be 
exposed to such things as Forms, repository, OJB, portal, petstore, 
linotype, etc., which could be *huge* selling points for Cocoon, IMHO.

I'm not that worried about people being confused by two flow 
implementations, if one of them is in core and the other one is in an 
unstable block. I suspect first thing most people will do after 
downloading is running the samples. If samples for unstable blocks sport 
a large, red-lettered warning, we have nothing to fear, again IMHO.

	Ugo


Re: Unstable stuff

Posted by Torsten Curdt <tc...@vafer.org>.
Gianugo Rabellino wrote:

> Torsten Curdt wrote:
> 
>>> Well, actually my point is about user awareness. Today you just 
>>> download Cocoon, read the docs, type ./build.sh and see some 
>>> fast-scrolling messages muttering about unstable stuff, and that's 
>>> it. I'm thinking of something more specific that forces the user to 
>>> know what she's doing. A different property/target (./build.sh 
>>> -Dinclude.unstable=true)? A different file to edit 
>>> (local.unstable.block.properties)? Everything would do: but clearly a 
>>> message that scrolls during the build is not enough.
>>
>>
>>
>> Well, having it disabled by default is a clear sign?
> 
> 
> That's not the case for a helluvalot of unstable stuff as of today...

I know  ...sorry my answer was misleading...
I like to propose to disable unstable blocks
by default.

cheers
--
Torsten


Re: Unstable stuff

Posted by Gianugo Rabellino <gi...@apache.org>.
Torsten Curdt wrote:

>> Well, actually my point is about user awareness. Today you just 
>> download Cocoon, read the docs, type ./build.sh and see some 
>> fast-scrolling messages muttering about unstable stuff, and that's it. 
>> I'm thinking of something more specific that forces the user to know 
>> what she's doing. A different property/target (./build.sh 
>> -Dinclude.unstable=true)? A different file to edit 
>> (local.unstable.block.properties)? Everything would do: but clearly a 
>> message that scrolls during the build is not enough.
> 
> 
> Well, having it disabled by default is a clear sign?

That's not the case for a helluvalot of unstable stuff as of today...

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)

Re: Unstable stuff

Posted by Torsten Curdt <tc...@vafer.org>.
> Well, actually my point is about user awareness. Today you just download 
> Cocoon, read the docs, type ./build.sh and see some fast-scrolling 
> messages muttering about unstable stuff, and that's it. I'm thinking of 
> something more specific that forces the user to know what she's doing. A 
> different property/target (./build.sh -Dinclude.unstable=true)? A 
> different file to edit (local.unstable.block.properties)? Everything 
> would do: but clearly a message that scrolls during the build is not 
> enough.

Well, having it disabled by default is a clear sign?

WDYT
--
Torsten