cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject [RRT] Cocoon 3? Defined by what it doesn't have
Date Sat, 03 Dec 2005 15:50:39 GMT
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.


Mime
View raw message