If Cocoon goes for a 3.0 approach, I would have to argue for a more
radical approach than "just fix things here and there". The problem is
one of focus. On paper Cocoon is a very capable framework. It
introduced us to a great new world of dynamic web sites. It's caching
system kicks tousche. And yet, the old guard is moving on and the new
guard doesn't know where to start. How do you go about creating a
simple web application? How do you integrate a couple web services into
a larger app? How do you do forms? etc.
Cocoon 2.0 is like Visual Studio.NET. On paper there are a hundred
things that kick but. When you use those features, it does make your
life easier. However, we don't allways use the cool features every
day. There are some things that would make every day life even better
such as programming by intention and refactoring tools. It just feels
like the same old thing rehashed and a couple features added on.
It should be like JetBrains IDEA. Almost every feature that is included
somehow makes daily development life easier. There is an early access
program to draw feedback from the user base. You don't have to think
about the features that you need because they are right there. Even
better is that the features are where you need them, and they aren't
obtrusive. You don't necessarily notice IDEA by itself, you notice it
by its absence.
We need to ask ourselves some hard questions: Do we really need it? (It
being whatever feature up for discussion) Does it make the user's life
easier? Can an Average Joe understand it? How does this fit in with
the overall vision? What is the overall vision?
I may be off base here, but I believe the majority of Cocoon's users are
developing /interactive web sites/ and not statically published sites.
The original vision has changed, but the enertia behind the
implementation has made Cocoon slow to adapt. What we need is
_just_enough_ to get the job done. There should be _one_way_ to do
things. Options don't make life easier--they make negotiations easier.
Are there things in the cooker that will put Cocoon in the sweet spot?
Absolutely, but fitting them into the current architecture has been
difficult. I'd assert because there are too many ways of doing the same
thing.
What about Risk?
----------------
There is risk involved in any start over/redesign. Now, I have been
involved in three wholesale redesigns of software at the various
companies I worked for in the past. Each one of them has been
successful because of the approach I take in doing it. I use every
experience to help make development and design better. Here is the
basic outline of the process:
1) Decide on a regular release schedule and employ a FedEx method of
development. For example, Cocoon 3 should be released AS IS every
month. The first versions may not have a whole lot there, but it should
give an indication of where we are going. This is our Early Access Program.
2) Test First Development. By writing tests _first_ we have a feeling
of _how_ something is used. It is our first feedback of whether or not
we are barking up the right tree. If we don't like the results
ourselves, it is doubtful anyone else will like it.
3) Forget the "Everything is a Component" mentality for a bit. Let's
see just how far containerless programming takes us. You might be
surprised. The number of moving parts is/should be relatively small.
Lets just start with good OOP to begin with.
4) Focus on the essentials. Deliver the most important things first.
Focus on stability and understandability at each stage. Compare how the
new feature is implemented with the whole. There should be a
continuity. You should be able to say that things "just work" and
everything "just fits".
You will be surprised at how quickly you can get to a point where Cocoon
3 is ready for prime-time. The fact that it will be much easier to use
than its predecessor will generate the excitement. We will have to
measure success by "gee its easy to do this in Cocoon, why is it so hard
here?" Forget about the wizbang hollabalou of featuritis or even
providing a solution for the XML technology du jour. Start with good
foundational principles. SEE HOW MUCH WE CAN LEVERAGE EXISTING TOOLS!!!
We need to see things from the eye of a user. If Cocoon is going to
make it through the long haul, it needs to pick up momentum. It will
only do that if we can generate excitement. Excitement surrounding some
new whizbang feature is temporary. Excitement because Cocoon saves time
and doen't require significant ramp up to understand it lasts much
longer. If you can tell a manager that they will save money by using
Cocoon, and prove it, then it will have a higher adoption rate in
corporate america. To obtain that goal it has to be solid. It has to
save time that would normally be spent writing config files or mapping
files. Etc.
Don't worry about things like database integration at this time. There
are other tools that handle that. Hibernate, Apache OJB. They both
handle object/relational mapping. Suggest the use of those for database
related work. Will there be dynamic pages? You bet ya, but they will
probably be a bit different than they are now.
We bemoan the fact that there aren't any/many tools for Cocoon
development, because we have our users working outside Java and in all
these scripting languages. You'd be surprised at just how good a Java
application can be. Be proud of your environment. Embrace it. Let
it's tools work for you. Simplify.
Be kick *ss because of what you _don't_ have. Create passionate users.
That's my two cents. I'm probably working on what will be my last
Cocoon app--unless we can create something that is just so good, and so
natural to use that I can't resist. But Cocoon in its current form is
just too much. Too much of everything. Too many languages to learn
(sitemap, XSP, JXL, CForm, JavaScript). Too many concepts to learn
(Avalon, SAX, Cache System). Too many ways of doing the same thing.
We need one vision, one goal, one way. We don't need to achieve it by
endless debates. We acheive it by trying a particular approach, and
getting feedback. The feedback from early adopters is very important,
and they are far enough removed that their opinions are more trustworthy
than our own.
