cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sun, 04 Dec 2005 03:27:39 GMT
Sylvain Wallez wrote:

> Berin Loritsch wrote:
>> There are two antipatterns that I see with Cocoon as a whole (from 
>> the current design aspect): Alphabet soup syndrome, and mixed 
>> metaphors.  The alphabet soup syndrome has to do with the fact that 
>> we are buzzword compliant without really taking the time to consider 
>> the affects on the whole.  The mixed metaphors has to do with all the 
>> components that overlap each other such as XMLizable and Generator.  
>> Every component should have a reason for being, and it should 
>> compliment the other components that already exist.  If you want to 
>> propose a new component that happens to overlap the responsibility of 
>> an existing component it is probably time to see which of the two is 
>> really needed.  Perhaps the older one needs to be retired.
>> When you look at the sitemap, it is not configuration--even though 
>> there is some configuration information in there.  A sitemap is a 
>> domain specific language expressed in XML.  My personal oppinion is 
>> that XML is poorly suited for any programming language.  The sitemap 
>> is a powerful concept--it is the implementation that feels a bit 
>> unnatural.  Think with the hat of someone who has never looked at 
>> Cocoon before.  You can probably assume that they have programmed in 
>> Java--but that's about it.
> You can't assume that: Cocoon is also one of the very few frameworks 
> that allows people with little programming knowledge to do some 
> non-trivial stuff, and we should not loose this goal. That's why I 
> consider keeping JavaScript as a glue language something important.

I don't know about you, but the reason most folks I know consider Cocoon 
is because it is written in Java.  I can guarantee you that not one 
non-technical person has ever tried to contribute anything more than a 
use-case spec to a Cocoon project I have worked on.  Why?  Because its 
not their job.  I would argue that JavaScript is not necessarily easier 
than Java.  It's different, but not necessarily easier.  Your person 
with little programming knowlege is going to be just as uneasy with 
JavaScript than Java.

The problem with JavaScript has to do with the fact that there is no IDE 
support.  There is no autocompletion.  There is no debugging.  There is 
no sane way to do test driven development with JavaScript.  Sure you get 
the scripting easy turn around, but you would also get that with JRuby.  
And JRuby has a unit testing framework so it would have a leg up.  The 
problem with an inconsistent environment is that in order for us to make 
it consistent, we would have to create a series of JSR 198 compliant IDE 
plugins for the integrated languages.  Oh, and wait for IDEs to ship 
with JSR 198 support.

I don't think anyone wanting to work on Cocoon is in the IDE business.  
When you have one consistent language, you leverage the work of others 
for your tool set.  Nothing special is required.  I honestly believe 
that direct interaction with JavaScript is not the way to invite people 
with little programming experience.  But that's my two cents.

View raw message