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.
- Re: [RT][long] Cocoon 3.0: the necessary mutation Berin Loritsch
-
