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