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
reloads.
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
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
