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



Reply via email to