You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephan Michels <st...@apache.org> on 2004/03/30 09:37:36 UTC
[VOTE] Move javaflow into scratchpad was RE: cvs commit:
cocoon-2.1/src/blocks/javaflow
Am Di, den 30.03.2004 schrieb Carsten Ziegeler um 09:07:
> Bertrand Delacretaz wrote:
> >
> > IMHO some kind of action is needed on this: either keep the
> > javaflow block as is, move it to the scratchpad or move it
> > somewhere else.
> >
> > Stephan, I understand the "public pressure" and excitement
> > prompted you to do the commit this (which is great: I'm as
> > impatient as anyone to play with javaflow), but this has been
> > done without taking Carsten's advice into account, which is not right.
> >
> > Could you clarify this with Carsten, or maybe restart a
> > [VOTE] about where to put javaflow?
> >
> > I don't want to rain on anyone's party, what Torsten and
> > Stephan are doing is just great, but let's not allow
> > disagreements to put clouds in this blue sky (hey I'm in
> > Spring mood ;-)
> >
> Hey, no problem - Stephan already contacted me and I think we have
> sorted everything out - if there was something to sort out at all
> between us.
> Now, as I still think that a new block gives the wrong impression
> (which user really reads that it's alpha?) I would prefer the
> scratchpad. I suggested to Stephan to start a vote about the place
> (block or scratchpad) and the majority wins. So everyone is happy
> and we all can enjoy the spring sun.
Thank you that you didn't take it wrong :)
Okay here another vote(and I wait more than 24h)
Move java into scratchpad?
[ ] Move it into scratchpad
[ ] Leave it where it is
[ ] Rename it to _______
My opinion is to leave it where it is, because I heard too much the
argument that "flow is a great thing, but javascript?!".
People already started to port the flow stuff for example to Struts, see
http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine
I think the java flow thing is too important to go with it into
scratchpad. For example you could also use Groovy to implement your
flow, because Groovy also produces Java classes.
I done a lot of afford to make it work like the javascript
implementation. So that it is only a choise, which language you
prefer.
But I'm curious about our opinions, Stephan Michels.
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Sylvain Wallez <sy...@apache.org>.
Stephan Michels wrote:
<snip/>
>Okay here another vote(and I wait more than 24h)
>
>Move java into scratchpad?
>
>[ ] Move it into scratchpad
>[X] Leave it where it is
>[ ] Rename it to _______
>
>
IMO, this is a very much expected feature that a lot of people are
waiting for.
It needs to be marked as experimental though, to prevent people using it
until it's fully mature (the feedback on samples shows that a bit time
is needed).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Ugo Cei <u....@cbim.it>.
Stephan Michels wrote:
> [ ] Move it into scratchpad
> [X] Leave it where it is
> [ ] Rename it to _______
Ugo
Re: unstable blocks
Posted by Joerg Heinicke <jo...@gmx.de>.
Antonio Gallardo <agallardo <at> agssa.net> writes:
> It was never was as documented, because of the Ant properties nature,
> always was the posibility to set exclude.block.xyz=[false, true]:
> http://ant.apache.org/manual/CoreTasks/property.html
Not quite true. @unless and @if (this is were the exclude (mapped to
unless.exclude) properties are used) don't look on the value of the property,
only the existence. This is why it only works because of the usage of
<condition>
<istrue/>
</condition>
Joerg
Re: unstable blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 30.03.2004 11:44, Bertrand Delacretaz wrote:
>> Because the current detection is based on the presence of the
>> "exclude.block.xyz" rather than its value, is that right?
>
> I guess this was "once upon a time". The current version even allows
> exclude.block.xyz=false and handles this the same way as the property
> would not be there because of the
> <condition>
> <istrue/>
> </condition>
> construct. So it's more a bad documentation at the moment. Quote from
> blocks.properties: "Remove blocks from your cocoon distribution by
> uncommenting the corresponding exclude property."
It was never was as documented, because of the Ant properties nature,
always was the posibility to set exclude.block.xyz=[false, true]:
http://ant.apache.org/manual/CoreTasks/property.html
I meet this first while imported the OJB block and I don't wanted to
compile it by default.
>>> ...So when doing it - what it is a good thing - we have to change the
>>> build process in relation to blocks selection. Isn't it possible to
>>> switch to include.block.{blockname}={true|false} syntax...
>>
>> I'd be +1 on this, "include.block.xyz" makes more sense.
>
> We can do it with changed documentation using exclude.block.xyz=false.
> As local.blocks.properties is loaded before blocks.properties and
> properties can not be reset, this would work.
>
> I personally prefer the other way around: include.block.xyz - including
> the consequences of forcing users to recopy the blocks.properties and
> resetting their blocks selection.
>
> I already have the include way working. It's backward compatible as long
> as the exclude=false is not already used.
>
> WDYT? Change only the documentation (to "use true|false") or
> additionally the property names from exclude to include.
+1 for Change only the documentation (to "use true|false") because in fact
this is the way t currently works.
+0 for additionally the property names from exclude to include. It is just
a matter of name. The question here is what is easier: define included or
excluded blocks. In my case, I have more excluded blocks than included
ones.
Best Regards,
Antonio Gallardo.
Re: unstable blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 31 mars 04, à 23:46, Joerg Heinicke a écrit :
> ...WDYT? Change only the documentation (to "use true|false") or
> additionally the property names from exclude to include....
I'm for changing from exclude to include, but you might want to ask for
a [VOTE], or at least a quick vote as this is a kind of "interface
change".
-Bertrand
Re: unstable blocks
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.03.2004 11:44, Bertrand Delacretaz wrote:
>> ...IMO having blocks disabled is not a problem. But the way
>> re-enabling them is. It's no longer possible to tell the user "copy
>> blocks.properties to local.blocks.properties and edit this one". I
>> already had this issue when only including woody block after
>> deprecation....
>
> Because the current detection is based on the presence of the
> "exclude.block.xyz" rather than its value, is that right?
I guess this was "once upon a time". The current version even allows
exclude.block.xyz=false and handles this the same way as the property
would not be there because of the
<condition>
<istrue/>
</condition>
construct. So it's more a bad documentation at the moment. Quote from
blocks.properties: "Remove blocks from your cocoon distribution by
uncommenting the corresponding exclude property."
>> ...So when doing it - what it is a good thing - we have to change the
>> build process in relation to blocks selection. Isn't it possible to
>> switch to include.block.{blockname}={true|false} syntax...
>
> I'd be +1 on this, "include.block.xyz" makes more sense.
We can do it with changed documentation using exclude.block.xyz=false.
As local.blocks.properties is loaded before blocks.properties and
properties can not be reset, this would work.
I personally prefer the other way around: include.block.xyz - including
the consequences of forcing users to recopy the blocks.properties and
resetting their blocks selection.
I already have the include way working. It's backward compatible as long
as the exclude=false is not already used.
WDYT? Change only the documentation (to "use true|false") or
additionally the property names from exclude to include.
Joerg
Re: unstable blocks (was: [VOTE] Move javaflow into scratchpad)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 30 mars 04, à 11:19, Joerg Heinicke a écrit :
> ...IMO having blocks disabled is not a problem. But the way
> re-enabling them is. It's no longer possible to tell the user "copy
> blocks.properties to local.blocks.properties and edit this one". I
> already had this issue when only including woody block after
> deprecation....
Because the current detection is based on the presence of the
"exclude.block.xyz" rather than its value, is that right?
> ...So when doing it - what it is a good thing - we have to change the
> build process in relation to blocks selection. Isn't it possible to
> switch to include.block.{blockname}={true|false} syntax...
I'd be +1 on this, "include.block.xyz" makes more sense.
-Bertrand
unstable blocks (was: [VOTE] Move javaflow into scratchpad)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.03.2004 10:33, Bertrand Delacretaz wrote:
> I like the idea, and it's easy to do as blocks.properties are generated
> from gump.xml.
Indeed.
> Problem is, this means shipping with many blocks disabled. I think this
> would warrant a notice at the top of the "blocks with samples" page,
> something like "see blocks.properties for a list of all available blocks".
IMO having blocks disabled is not a problem. But the way re-enabling
them is. It's no longer possible to tell the user "copy
blocks.properties to local.blocks.properties and edit this one". I
already had this issue when only including woody block after deprecation.
So when doing it - what it is a good thing - we have to change the build
process in relation to blocks selection. Isn't it possible to switch to
include.block.{blockname}={true|false} syntax as this property is not
used directly in blocks-build.xml, but mapped to a property
unless.exclude.block.{blockname} at the moment:
<condition property="unless.exclude.block.fop">
<istrue value="${exclude.block.fop}"/>
</condition>
Doing the mapping in another should not be impossible, allows us to use
the more intuitive notation proposed above and removes the need for
adding blocks.properties at all.
Joerg
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Gianugo Rabellino <gi...@apache.org>.
Bertrand Delacretaz wrote:
> Le 30 mars 04, à 10:20, Marc Portier a écrit :
>
>> ...just an idea popping up: why not reverse the default
>> exclude.block.XXX setting for the unstable ones?
>>
>> then people will need to enable those and thus be more explicitely
>> confronted?...
>
>
> I like the idea, and it's easy to do as blocks.properties are generated
> from gump.xml.
>
> Problem is, this means shipping with many blocks disabled. I think this
> would warrant a notice at the top of the "blocks with samples" page,
> something like "see blocks.properties for a list of all available blocks".
Deal. In any case, though, having those blocks excluded by default might
boost us to take the "unstable" tag out. Right now there is little or no
practical advantage, but just add some and you'll see us lazy butts
start to work. :-)
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: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 30 mars 04, à 10:20, Marc Portier a écrit :
> ...just an idea popping up: why not reverse the default
> exclude.block.XXX setting for the unstable ones?
>
> then people will need to enable those and thus be more explicitely
> confronted?...
I like the idea, and it's easy to do as blocks.properties are generated
from gump.xml.
Problem is, this means shipping with many blocks disabled. I think this
would warrant a notice at the top of the "blocks with samples" page,
something like "see blocks.properties for a list of all available
blocks".
-Bertrand
Re: Subversion support on eclipse
Posted by Antonio Gallardo <ag...@agssa.net>.
Gianugo Rabellino dijo:
> Antonio Gallardo wrote:
>
>> Gianugo Rabellino dijo:
>>
>>>Marc Portier wrote:
>>>
>>>
>>>>>(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
>>>>
>>>>
>>>>-1 on dir structure, cvs hastle would kinda prevent blocks of becoming
>>>>stable, right?
>>>
>>>Right (how I wish that we would switch to Subversion anytime soon...).
>>
>>
>> Hi:
>>
>> I am waiting for Fedora Core 2 with Subversion included! When it happens
>> I
>> will push too for the Subversion usage. :-)
>
> <rant>
>
> Well, I feel a bit like an old aunt sitting on the porch and muttering
> about the good old times, but I really feel at loss when I see what is
> supposedly the cream of the crop of techies around the world becoming
> sissies when a far better technology isn't supported in their favorite
> GUI... I really fail to see why the most important Subversion migration
> issue is lack of support in the IDE.
ROTFL!
> Actually, as a CLI diehard I'm used to fire Eclipse only for seriously
> tangled stuff or for debugging: my typical development environment is
> CLI-based anyway (vim+ant+cvs/svn) so I might be biased but, ah, the
> good old times when Real Programmers did punched cards... :-)))
>
> </rant>
Hi Mr. Bruce Willis! :-D
Well, I just saw a glipse of "good times" on the corner of my eye. Then,
the world evolutioned as we know it today.
I almost never use a debugger.... In the good times there was not
debuggers and at the University they was almost fobidden in the first
year. The first one used was dbx (is this the right name?) in a UNIX
terminal, then Turbo Debugger from Borland (that was really cool!, I liked
the disassembler option) for Assembler and C.
In my nearly 2 years using Cocoon I run it maybe handful of time and that
is too many times. I prefer to insert some temporary log instructions
between the code when things goes really bad. But almost all the time the
syntax assistant of eclipse is enough to write good code.
vim just when ssh and CLI and some /etc editing.
cvs for a testing version of cocoon in another directory to test after
commiting.
My current development environment is:
eclipse: For cvs downloading and Java writing.
JEdit for anything that is not Java (XML, Javascript, etc).
ant for building all the stuff: Cocoon, OJB, Druid and others libs. In
some cases Ant called from eclipse.
:-D
Best Regards,
Antonio Gallardo.
Re: Subversion support on eclipse
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> ah, the
> good old times when Real Programmers did punched cards... :-)))
... and took 20 years to do anything ;-)
--
Stefano.
Re: Subversion support on eclipse
Posted by Gianugo Rabellino <gi...@apache.org>.
Antonio Gallardo wrote:
> Gianugo Rabellino dijo:
>
>>Marc Portier wrote:
>>
>>
>>>>(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
>>>
>>>
>>>-1 on dir structure, cvs hastle would kinda prevent blocks of becoming
>>>stable, right?
>>
>>Right (how I wish that we would switch to Subversion anytime soon...).
>
>
> Hi:
>
> I am waiting for Fedora Core 2 with Subversion included! When it happens I
> will push too for the Subversion usage. :-)
<rant>
Well, I feel a bit like an old aunt sitting on the porch and muttering
about the good old times, but I really feel at loss when I see what is
supposedly the cream of the crop of techies around the world becoming
sissies when a far better technology isn't supported in their favorite
GUI... I really fail to see why the most important Subversion migration
issue is lack of support in the IDE.
Actually, as a CLI diehard I'm used to fire Eclipse only for seriously
tangled stuff or for debugging: my typical development environment is
CLI-based anyway (vim+ant+cvs/svn) so I might be biased but, ah, the
good old times when Real Programmers did punched cards... :-)))
</rant>
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/)
Subversion support on eclipse (was: Re: [VOTE] Move javaflow...)
Posted by Antonio Gallardo <ag...@agssa.net>.
Gianugo Rabellino dijo:
> Marc Portier wrote:
>
>>> (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
>>
>>
>> -1 on dir structure, cvs hastle would kinda prevent blocks of becoming
>> stable, right?
>
> Right (how I wish that we would switch to Subversion anytime soon...).
Hi:
I am waiting for Fedora Core 2 with Subversion included! When it happens I
will push too for the Subversion usage. :-D
Wait! I am also pushing on the eclipse side too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37154
For all eclipse users: Please vote for Subversion support! :-D
Best Regards,
Antonio Gallardo
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Gianugo Rabellino <gi...@apache.org>.
Marc Portier wrote:
>> (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
>
>
> -1 on dir structure, cvs hastle would kinda prevent blocks of becoming
> stable, right?
Right (how I wish that we would switch to Subversion anytime soon...).
>> unstable.blocks.properties that Joe User *has* to read to compile such
>> stuff and some more warning around...
>>
>
> just an idea popping up: why not reverse the default exclude.block.XXX
> setting for the unstable ones?
>
> then people will need to enable those and thus be more explicitely
> confronted?
That is the main purpose, yes. Could be enough as a first step.
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: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Marc Portier <mp...@outerthought.org>.
Gianugo Rabellino wrote:
> Stephan Michels wrote:
>
>>> Hey, no problem - Stephan already contacted me and I think we have
>>> sorted everything out - if there was something to sort out at all
>>> between us. Now, as I still think that a new block gives the wrong
>>> impression
>>> (which user really reads that it's alpha?) I would prefer the
>>> scratchpad. I suggested to Stephan to start a vote about the place
>>> (block or scratchpad) and the majority wins. So everyone is happy
>>> and we all can enjoy the spring sun.
>>
>>
>>
>> Thank you that you didn't take it wrong :)
>>
>> Okay here another vote(and I wait more than 24h)
>>
>> Move java into scratchpad?
>>
>> [ ] Move it into scratchpad
>> [+1] Leave it where it is
>> [ ] Rename it to _______
>
>
> (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
-1 on dir structure, cvs hastle would kinda prevent blocks of becoming
stable, right?
> unstable.blocks.properties that Joe User *has* to read to compile such
> stuff and some more warning around...
>
just an idea popping up: why not reverse the default exclude.block.XXX
setting for the unstable ones?
then people will need to enable those and thus be more explicitely
confronted?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
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
Unstable stuff (was: Re: [VOTE] Move javaflow into scratchpad)
Posted by Gianugo Rabellino <gi...@apache.org>.
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: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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.
-Bertrand
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Gianugo Rabellino <gi...@apache.org>.
Stephan Michels wrote:
>>Hey, no problem - Stephan already contacted me and I think we have
>>sorted everything out - if there was something to sort out at all
>>between us.
>>Now, as I still think that a new block gives the wrong impression
>>(which user really reads that it's alpha?) I would prefer the
>>scratchpad. I suggested to Stephan to start a vote about the place
>>(block or scratchpad) and the majority wins. So everyone is happy
>>and we all can enjoy the spring sun.
>
>
> Thank you that you didn't take it wrong :)
>
> Okay here another vote(and I wait more than 24h)
>
> Move java into scratchpad?
>
> [ ] Move it into scratchpad
> [+1] Leave it where it is
> [ ] Rename it to _______
(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...
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: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
> Okay here another vote(and I wait more than 24h)
>
> Move java into scratchpad?
>
> [ ] Move it into scratchpad
> [x] Leave it where it is
> [ ] Rename it to _______
Hiding anything in scratchpad does not help
anything IMO. The block is marked unstable
and this should give the right perception.
scratchpad = big mess
It's good for single classes try-outs where
a block does not make sense. But blocks are
much more structured - which is good IMO.
cheers
--
Torsten
Re: [VOTE] Move javaflow into scratchpad was RE:
cvscommit: cocoon-2.1/src/blocks/javaflow
Posted by Antonio Gallardo <ag...@agssa.net>.
Stephan Michels dijo:
> But I think it's more the time to talk about
> to cut the CVS repository into cocoon-blocks and cocoon-core, which
> means a really small and slim core with the components, which are
> nessecary for a bootstrap system.
+1 too. That always was been told and never done.
> Perhaps this time with svn ;-)
Here is my +1. - I hope this last one will avoid more ranting ;-D
Best Regards,
Antonio Gallardo
Re: [VOTE] Move javaflow into scratchpad was RE: cvs
commit: cocoon-2.1/src/blocks/javaflow
Posted by Stephan Michels <st...@apache.org>.
Am Di, den 30.03.2004 schrieb Marc Portier um 10:32:
> my argumentation is primarily short-term/pragmatic:
>
> starting at two observations:
> 1/ this is cool stuff and as far as I can see the reactions just about
> everyone here is salivating and wants to interact with that code
Yes, seems so. And I'm glad about it.
> 2/ the block-unit is the only thing our current infrastructure is
> offering to efficiently and atomically snap in and out certain functionality
>
> Taking this pragmatic view I can't see but a lot of similarity between
> this block and a lot of others...
I have the same view, the current block intrastructure is the only way
to make the build modular. Move all things, which are unstable, in one
scratchpad-block doesn't help anyone.
I can see Carsten's POV, and understand the fear that we get too much
block during the time. But I think it's more the time to talk about
to cut the CVS repository into cocoon-blocks and cocoon-core, which
means a really small and slim core with the components, which are
nessecary for a bootstrap system.
Perhaps this time with svn ;-)
Stephan.
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Marc Portier <mp...@outerthought.org>.
Stephan Michels wrote:
>
> [ ] Move it into scratchpad
> [X] Leave it where it is
> [ ] Rename it to _______
>
>
my argumentation is primarily short-term/pragmatic:
starting at two observations:
1/ this is cool stuff and as far as I can see the reactions just about
everyone here is salivating and wants to interact with that code
2/ the block-unit is the only thing our current infrastructure is
offering to efficiently and atomically snap in and out certain functionality
Taking this pragmatic view I can't see but a lot of similarity between
this block and a lot of others...
IMHO, were this block will take us in the future is not the question
here and now..
regards,
-marc=
>
> My opinion is to leave it where it is, because I heard too much the
> argument that "flow is a great thing, but javascript?!".
> People already started to port the flow stuff for example to Struts, see
> http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine
>
> I think the java flow thing is too important to go with it into
> scratchpad. For example you could also use Groovy to implement your
> flow, because Groovy also produces Java classes.
>
> I done a lot of afford to make it work like the javascript
> implementation. So that it is only a choise, which language you
> prefer.
>
> But I'm curious about our opinions, Stephan Michels.
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Reinhard Pötz <re...@apache.org>.
Stephan Michels wrote:
> Thank you that you didn't take it wrong :)
>
>Okay here another vote(and I wait more than 24h)
>
>Move java into scratchpad?
>
>[X] Move it into scratchpad
>[ ] Leave it where it is
>[ ] Rename it to _______
>
>
>
>My opinion is to leave it where it is, because I heard too much the
>argument that "flow is a great thing, but javascript?!".
>People already started to port the flow stuff for example to Struts, see
>http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine
>
>I think the java flow thing is too important to go with it into
>scratchpad. For example you could also use Groovy to implement your
>flow, because Groovy also produces Java classes.
>
>I done a lot of afford to make it work like the javascript
>implementation. So that it is only a choise, which language you
>prefer.
>
>
Your work is really appreciated!
>But I'm curious about our opinions, Stephan Michels.
>
>
I think we shouldn't ship Javaflow as block because this gives our user
base the wrong impression. I'd like to see it in scratchpad and as soon
as it is stable (community, technology) it should become part of Cocoon
core. BTW, this is the reason why we have a separate scratchpad block!
Speaking in Cocoon 2.2 (3.0) semantics, it should be IMO (as the
different environments, the Javascript-Flowinterpreter, ...?) in the
middle between blocks and core.
Avoiding balkanization I'm -1 on other implementation than JS and Java
in the Cocoon CVS. But this shouldn't prevent people to provide them or
to provide e.g. Groovy examples somewhere else. But please not in our
CVS ... things are complicated and messed up enough ...
--
Reinhard
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 30 mars 04, à 09:37, Stephan Michels a écrit :
> Move java into scratchpad?
you mean javaflow for sure ;-)
>
> [ ] Move it into scratchpad
> [+1 ] Leave it where it is
> [ ] Rename it to _______
But I'd add very visible mentions of the experimental status of this
block: on the samples page at least (haven't looked at it yet, there
might be such mentions already).
-Bertrand
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit:cocoon-2.1/src/blocks/javaflow
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Stephan Michels dijo:
>
>>Okay here another vote(and I wait more than 24h)
>>
>>Move java into scratchpad?
>>
>>[X] Move it into scratchpad
>>[ ] Leave it where it is
>>[ ] Rename it to _______
>
>
> There is not JavascriptFlow Block.
>
Antonio,
While I share your feeling for simmetry and the wish to treath equal
things in an equal manner...
and I respect your opinion in this matter
However, this is precisely the kind of future discussions I was hinting
about in my short-term/pragmatic reasoning earlier
To put it bluntly:
this is not a vote on the position of javascript, is it?
<snip/>
>
> I think it is a big improvement and thanks both of you. Mainly because I
> hope we will see the born of future implementations in diferent languages.
> What at first sight can looks like a "balkanization" [(TM) by Stefano] is
> good because allow people not Java (or Javascript) oriented to jump in the
> Cocoon way. And this is good.
>
I honnestly hope that the future will prove this,
However, I just don't think this hope is a basis for the scratchpad
decission
> Best Regards,
>
> Antonio Gallardo
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [VOTE] Move javaflow into scratchpad was RE: cvs
commit:cocoon-2.1/src/blocks/javaflow
Posted by Antonio Gallardo <ag...@agssa.net>.
Stephan Michels dijo:
> Okay here another vote(and I wait more than 24h)
>
> Move java into scratchpad?
>
> [X] Move it into scratchpad
> [ ] Leave it where it is
> [ ] Rename it to _______
There is not JavascriptFlow Block.
> My opinion is to leave it where it is, because I heard too much the
> argument that "flow is a great thing, but javascript?!".
> People already started to port the flow stuff for example to Struts, see
> http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine
I read it and wonder if he knows that already some people is
"manipulating" DAO beans with OJB using the nasty javascript Flow Engine
in a very easy way. :-P (See the bottom line of the above post).
> I think the java flow thing is too important to go with it into
> scratchpad. For example you could also use Groovy to implement your
> flow, because Groovy also produces Java classes.
Agree.
> I done a lot of afford to make it work like the javascript
> implementation. So that it is only a choise, which language you
> prefer.
>
> But I'm curious about our opinions, Stephan Michels.
I think it is a big improvement and thanks both of you. Mainly because I
hope we will see the born of future implementations in diferent languages.
What at first sight can looks like a "balkanization" [(TM) by Stefano] is
good because allow people not Java (or Javascript) oriented to jump in the
Cocoon way. And this is good.
Best Regards,
Antonio Gallardo
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Michael Melhem <mi...@managesoft.com>.
>
> [ ] Move it into scratchpad
> [X] Leave it where it is
> [ ] Rename it to _______
Since this block is marked unstable, I dont see the need to move it
anywhere else.
cheers,
Michael
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.03.2004 09:37, Stephan Michels wrote:
> Move java into scratchpad?
>
> [ ] Move it into scratchpad
> [ ] Leave it where it is
> [X] Rename it to "jflow"
Joerg
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Tim Larson <ti...@keow.org>.
On Tue, Mar 30, 2004 at 08:16:32AM -0800, Christopher Oliver wrote:
> Stephan Michels wrote:
>
> >Thank you that you didn't take it wrong :)
> >
> >Okay here another vote(and I wait more than 24h)
> >
> >Move java into scratchpad?
> >
> >[ ] Move it into scratchpad
> >[+1 ] Leave it where it is
> >[ ] Rename it to _______
> >
> Chris
--Tim Larson
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Christopher Oliver wrote:
> Stephan Michels wrote:
>
>> Thank you that you didn't take it wrong :)
>>
>> Okay here another vote(and I wait more than 24h)
>>
>> Move java into scratchpad?
>>
>> [ ] Move it into scratchpad
>> [+1 ] Leave it where it is
>> [ ] Rename it to _______
>
Vadim
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Posted by Christopher Oliver <re...@verizon.net>.
Stephan Michels wrote:
>Thank you that you didn't take it wrong :)
>
>Okay here another vote(and I wait more than 24h)
>
>Move java into scratchpad?
>
>[ ] Move it into scratchpad
>[+1 ] Leave it where it is
>[ ] Rename it to _______
>
>
>
>
Chris
RE: [VOTE] Move javaflow into scratchpad was RE: cvs commit:cocoon-2.1/src/blocks/javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
> Okay here another vote(and I wait more than 24h)
:)
And I'm the first one to vote !!!
>
[X] Move it into scratchpad
Carsten