cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: FYI: Using Java to define Cocoon Flow
Date Tue, 13 May 2003 17:48:21 GMT
on 5/13/03 12:45 AM Bertrand Delacretaz wrote:

> Le Mardi, 13 mai 2003, à 01:15 Europe/Zurich, Stefano Mazzocchi a écrit 
> :
> 
> 
>>....I'll tell you what: if I had a java implementation of flow in 
>>cocoon
>>*today*, I would still use the javascript version for these 
>>reasons:....
> 
> 
> <snip valid reasons/>
> 
> I agree that for short flowscripts, javascript is very well suited, 
> concise etc.
> (and aren't all flowscripts supposed to be short?)
> 
> What I find great though, is the fact that someone is able to come up 
> with an alternate language for the flow in a fairly short time (once 
> continuations are available in said language) - as I said in my blog it 
> is a testimony to the modularity and clean implementation of Cocoon, 
> Avalon and Flow.
> 
> It is certainly a good thing that the Cocoon team concentrates on 
> javascript for Flow - it works, there are samples, etc.
> 
> But alternate implementations should be encouraged IMHO, even if there 
> is a clear bias in favor of the "official" one. Having more stuff built 
> upon a framework always increases the quality of the framework by 
> uncovering more bugs and design problems.

I completely agree with you on this, Bertrand. Totally.

My point was another one: the use of javascript as a glue between
components and solid practices, IMO, is the best of both worlds: weak
typing for glue, strong typing for the components and the frameworks.

I would like you to note that this is *exactly* the same approach taken
by DHTML and that DHTML has a very bad reputation because of browser
incompatibility, but with mozilla getting solid and *very* adherent to
standard, I forsee DHTML (that is XHTML+CSS2+DOM2+Javascript) to bloom
in the next few years.

So, imagine the picture where the flow of your web application is
uniformly spread across and client *and* the server.

This is exactly what I'm doing with Linotype and, boy, it's the most
productive system for software developer i've seen in my entire life in
terms of RAD/elegance ratio. (RAD tools tend to write shitty code and
good code was not RAD at all!)

This is changing. With flowscript, Cocoon will ride the wave of the rich
clients by making it *very* easy for people coming from the flash/DHTML
world to hook into the server side... but given the FOM limitations,
those script kiddies won't ruin the architecture with hacks, as they do
when they land in thing slike Struts, for example, where the holes are
covered by best practices, not by real framework limitations.

Less is more.

flowscript makes it verbose and hacky to write business logic in
javascript. it *feels* wrong. Even at a script kid eye.

if you allow Sylvain to use his eclipse to save him keystrokes on its
java flow, he won't abuse it, but newbies will, big time! and they will
start writing a mile-long c-like flow with a huge number of functions,
some called by the sitemap, some implementing business logic. Result: a
total mess.

So, sorry Sylvain, but I'd rather extend eclipse with a flowscript
editor than turning the flow to java.

This said, I won't stop people from exploring alternatives ideas and
implementations, no way, if that was the case, we wouldn't have the flow
in the first place :-)

-- 
Stefano.



Mime
View raw message