Gianugo Rabellino wrote:
On Jun 5, 2004, at 7:19 PM, Antonio Gallardo wrote:
Hi:
After 11 hours of work, the first implementation of a Groovy Flow engine for Cocoon is working on my hard drive.
Cool! But. gosh, I hate to rain on anyone's parade, yet I think it was kinda decided yesterday to focus on solidifying JS instead than Groovy. Don't get me wrong, I like Groovy a lot and I sure appreciate your work, yet I have this feeling that committing it now would just confuse users even more. Flow is already feeling like quicksand, adding yet another language without being able to guarantee solid contracts is risky business. I'd much rather see a bulletproof JS/Java foundation before delving into a partially working Groovy implementation. So, this is a sad -0 here.
First of all: thx toGianugo for expressing so well what I was thinking as well (actually I've even been waiting/hoping for this message to hit the thread)
Observing:
The missing established best practice and/or clear examples on the distincition between Java code and javascript lines, combined with the feeling of opening the can of rhino-worms when getting into the zone of the Scriptable Java wrappers, the not really settled discussion on 'how less is more enough' regarding the flow api, the missing integrated refactoring js-ide's, topped with the side-stander observation that we easily seem to attract a whealth of expression languages at various places without much effort (so it seems) to unify and hide behind some interface... and yaddayadda
Well, yeah it's probably an easy conclusion to make: we have enough issues already at the table around flow not to be scattering the resources around.
Oddly enough though I'm still arriving to the opposite conclusion on deciding to commit and share the groovy flow with the group though.
<replay what="old wine in new wineskins">
At the danger of making myself the ol' stubborn bull in the barn (who is still nurturing fond memories on some ancient thread that combined topics like 'Generalized Flow' and 'Balkanization', uhuh) I'ld have to say that I'm still convinced that the goal of 'achieving the bulletproof Flow foundation and contract' in my head is about negotiating between more then one (actually the more the better) possible implementations and views around controlling web-app flow (uri redirects, state per click, state per use case, stateless actions, event-handlers,...)
Yes, I'm folkloristic-ally still convinced there is unifying thought behind the continuations, javaflow, apples and actions (I just haven't got time enough to put my rather limited mind organized around it)
</replay>
In any case:
The tention/challenge is between gaining better insight from a broader view versus moving faster by deliberately ignoring part of the 'Reality'.
IMHO: In order to allow each of us (guided by cruel Darwin playing the dice) to make his own preference in this issue, we should chose to commit, discuss and share...
(hereby my +1 to that)
-marc= (well aware of the fact that there isn't always much pragmatic or observable value in the proposed attitude of intellectual correctness)
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
