cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sat, 03 Dec 2005 17:55:31 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>> Tell me your thoughts. Am I completely off-track, or do you also want to 
>> build this great new thing?
> Hmm, I don't know - I think your ideas make mostly sense (we already
> discussed some of them in the past), but for me these are technical
> details (I don't say that they are not important). But I think, we need
> a vision for 3.0 - what do we want to achieve?

Here's what I want to achieve:
- simplicity: use less XML files, have a small number of versatile but 
understandable components
- productivity: sensible defaults, fast try/fail cycles
- scripted J2EE: JDK 1.6 will ship with Rhino, meaning a lot of products 
will offer JS as a scripting language. Cocoon is the first one.
- integration: integrating something in Cocoon is easy, but the other 
way around is a mess. A smaller set of loosely coupled features can 
allow people to come to Cocoon to grab what they need (e.g. a pipeline 
engine), and hopefully later be interested by its other features
- considering the architectural paradigm changes that comes with Ajax 
apps, that place the controller at the center of the picture and change 
the nature of the request/response model by moving away from full page 

> Now, most of the alternatives to Cocoon have one thing in common: they
> are easy too learn and you can start quickly (and most of them have the
> "start quick and fail later" problem but that's another story). Whereas
> if you want to use Cocoon, you can't start right away. There is so much
> to learn, so many different files you have to write/adjust.
> Why do managers love Struts or JSF? It's a "standard" but even more
> important, they have tools. Fancy tools sell your product, that's the
> bitter truth. And I have the feeling, that products, that don't have
> tools but are "just cool", will not be used anymore (it's just a feeling).

Tools are actually a way to hide complexity. What if the tool you need 
is a plain Java IDE with a JavaScript plugin because all you have is a 
pipeline API and Flowscript/Javaflow?

> I think from a technological point of view, Cocoon is still at the top,
> we can easily support ajax, we could integrate Spring or spring flow if
> required etc. But I think, developing with Cocoon needs to be more
> productive than it is today.
> Just an example, CForms is a great framework, it offers everything you
> need - but providing a simple form for editing a bean requires several
> different files to be created.

Yup. Totally agree.

> In the end it comes down to the following two things: we need a good
> documentation and it must be productive to develop with Cocoon.

Sure, but can we be productive enough with today's Cocoon?

> I'm not a believer of all these "too-much-magic" frameworks or
> generating stuff. So I think using Cocoon should be simpler and we need
> tools. Why don't we have tools? For example, we don't have a sitemap
> editor, we even don't have a simple tool that can validate a sitemap or
> an xconf etc. Not to mention that developing with Cocoon currently
> requires to define your own build system.
> For some of our problems, we already have answers, being it using Maven,
> implementing real blocks, adding this new feature here and there. And we
> are very good in agreeing on these things, but we are not that good in
> actually doing them :(
> So, yes, I think we need some radical changes for 3.0 - but I fail to
> see what these should be. There are two things clear for me: developing
> with Cocoon must get easier, and we'll get this with Maven - and we need
> much better docs. (Of course, the docs have heavily improved in the last
> months but many things are simply not documented at all yet).

Sorry, but saying that a build tool is the solution to our problems is 
burying you head in the sand, as it's just trying to automate the 
management of complexity.

> And to give some more meat to discuss (or rant about) as I will be
> offline for the next ten days: I'm still in the "we don't need OSGi"
> camp (as some of us are here), as I still believe that it adds to much
> complexity. But as others (who I trust) believe in this and as I don't
> have time to work on this, the only way to progress is to not block
> those who have time to do something. But I come more and more to the
> conclusion that we simply should use Spring as the base framework and
> build some class loading stuff on top of it (which we already have with
> the sitemap classloaders). That would be a simple but sufficient solution.

And IMO we don't even need that. As was Gianugo said later, the whole 
blocks stuff, if you think about it, is just about adding an additional 
level of complexity in the hope to hide the current one. Just like the 
sophisticated build tool, actually.


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message