Gianugo Rabellino wrote:
On 12/2/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
All this to say that if we want Cocoon to have a bright future, it must
go through a mutation. This RT dumps my current ideas about this,
depicting something that IMO better fits today's needs while taking into
account many years of innovation and what we learned from them.
Thanks *so* much for this, Sylvain. Your words echo what I've been
thinking from a long time: Cocoon is a great framework with lots of
unexpressed potential, and I definitely think that in this stage of
our lives, we need a revolution much more than an evolution. All the
latest and greatest in Cocoon development lately have been little more
than finding solutions to our own problems, instead than questioning
ourselves with the idea of changing perspectives and seeing the real
problems. A perfect example, to me, is the whole block scenario: over
the last few months I came to realize that if we need such a
sophisticated beast to manage our complexity, this means that we are
just too complex, period.
So, back to the revolution scenario, I'd love to throw my pebbles in
the lake and see if they can be of any use: first of all, I don't
really believe that the situation to our problems can happen via
evolution (say 2.x stuff): if you look at what people is expecting
today, you'll notice how things might be best accomplished by a clean
slate approach, which takes issues such as backward compatibility with
a grain of salt, being ready to deal with it, swallow the idea of
either sticking to 2.x (which will still be around for a long time) or
rewrite good portions of what you've got and be done with it. If we
are to revolutionize, well, this is a good time to have a look at the
war we have been fighting and the battles we won and lost, in order to
learn from our mistakes.
Starting from our mistakes, today I tend to say that one of the areas
where we have completely failed is the idea of not-so-technical people
managing the applications: we had been figuring out, in our little SOC
world, that people would have written bits of functionality, with
management tying them into sitemaps. The equation
non-technical-people=XML files would have worked like a charm, but
what's actually happening is that sitemaps are strongly in the
developer's domain, and developers aren't that comfortable with angle
brackets and bloated syntaxes. The next incarnation of the sitemap,
whatever that's going to be, must be as developer-friendly as
possible, which means concise and effective, something we don't really
have today.
That's where dynamic pipelines, i.e. a programmatic access to pipelines,
can be of great help.
The second point I hate most in today's Cocoon is the TIMTOWDI effect.
Cocoon applications, written with no discipline, unfortunately can be
as messy as Perl or even worse: everytime I'm faced with a new
Cocoon-based app I tend to have a way too hard time understanding what
the flow is like and which components are used in what order:
component declaration, private pipeliens, actions, mounts and the
cocoon:/ protocol tend to get too much in the way of a developer, and
I'd love to see it changed. True, there is no need to look any further
than the sitemap to see what happens (well, flow changed the picture
quite a bit there), but is the sitemap is a tangled mess, this is of
little help.
Actually, with the pipeline API, the ability to expand aggregations
inline and virtual pipeline components, I'm wondering if we still need
the "cocoon:" protocol at all.
<snip/>
+1 for a POJO based Cocoon, not sure about container replaceability
(tends to be an Holy Grail nowadays).
Right. Let's keep the POJO thing and provide integration with a single
container, but still allowing people to use another one if they have the
need to. Practically, that means avoiding at all costs dependencies of
the code on the container. Pure POJOs may not always be practical
(thinking mainly here about component selectors), and in that case we
must define our own lightweight abstractions that fit our needs and
bridge to the actual container.
My impression is that with all these changes, Cocoon will be sexy again.
A few words about the "sexy" stuff which has been perceived
differently in the responses so far: we need sexy stuff if we want to
have an healthy, diverse and growing community. Sexyness and adoption
generally go hand in hand.
Yup.
Add a bit of runtime analysis of databases and automatic generation of
CForms to the picture, and you have something that has the same
productivity as RoR, but in a J2EE environment. It also includes what I
learned when working on Ajax and the consequences it has on the overall
system architecture.
Don't forget tools! In Cocoon 2.x it's basically impossible to provide
decent productivity tools because there are too many components with
contracts being too loose. If Cocoon 3 has to happen, this is one of
the points I will tend to commit myself to, ensuring that every
functionality can be easily managed, deployed and monitored (JMX,
anyone?) and that those mundane and boring tasks that affect a Cocoon
developer's life can be done using some fancy web interface or an IDE.
JDK 1.5 has a JMX console and AFAIU Spring allows to easily JMX-ify
beans. So that may come for free.
Tell me your thoughts. Am I completely off-track, or do you also want to
build this great new thing?
I'm with you with all my CFT
CFT ???
Hope to talk about all this with some fellow Cocooners next week in San Diego.
Yep. An intersting discussion subject :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
