cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Date Tue, 30 Mar 2004 07:59:46 GMT
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


Mime
View raw message