cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sat, 03 Dec 2005 04:58:50 GMT
Sylvain Wallez wrote:

> Hi all,
> For many years, I have been more than happy with Cocoon, enjoying the 
> power and ease it brought for both publication and webapp projects. 
> Over the last months however, other feelings have emerged: there are 
> things that are definitely overly complex in Cocoon, and there have 
> been some emerging frameworks leading to "wow, cool!" reactions rather 
> than "yeah, yet another one". Also, I strongly believe that the Ajax 
> revolution is quickly obsoleting the traditional 
> reload-page-on-user-action model that prevailed on the web up to 
> recently and requires frameworks that help building these new kinds of 
> applications.
> 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.

If I may, I'd like to suggest a process for identifying what should be, 
and how to make the design decisions.  Bear with me a bit as I use 
something totally unrelated to programming in general.

When a traditional Japanese sword polisher goes about a new project, he 
arranges his tools in his workspace so that he does not have to think 
about which one he needs next.  His tools are essentially a set of 
progressively finer grained stones and water.  The polisher starts with 
the course grained stones to set the geometry/structure of the blade in 
place.  As he works in one small area, he constantly checks his work 
against the whole blade.  Uneven, or inconsistent work will ruin his 
efforts.  As he progresses toward the fine grained stones, he is 
concentrating on bringing out the subtle detail forged into the blade 
itself.  Again, all the time checking his local work against the whole.

Now, I said all that to say this:

Simplicity is fun to use, but hard to do.  You have to take a process 
like the sword polisher in order to arrive at something brilliantly 
simple.  Little things matter.  If you can make the user's life even 
just a little bit easier, it is a worthwhile goal.  As you add a new 
feature, use it a bit and ask yourself if it is making your life easier 
or harder.

There are two antipatterns that I see with Cocoon as a whole (from the 
current design aspect): Alphabet soup syndrome, and mixed metaphors.  
The alphabet soup syndrome has to do with the fact that we are buzzword 
compliant without really taking the time to consider the affects on the 
whole.  The mixed metaphors has to do with all the components that 
overlap each other such as XMLizable and Generator.  Every component 
should have a reason for being, and it should compliment the other 
components that already exist.  If you want to propose a new component 
that happens to overlap the responsibility of an existing component it 
is probably time to see which of the two is really needed.  Perhaps the 
older one needs to be retired.

When you look at the sitemap, it is not configuration--even though there 
is some configuration information in there.  A sitemap is a domain 
specific language expressed in XML.  My personal oppinion is that XML is 
poorly suited for any programming language.  The sitemap is a powerful 
concept--it is the implementation that feels a bit unnatural.  Think 
with the hat of someone who has never looked at Cocoon before.  You can 
probably assume that they have programmed in Java--but that's about it.  
Now think about the number of technologies that someone has to learn in 
order to be affective with Cocoon.  If we have Javascript, Java, Jexl, 
etc. we are introducing complexity and learning curve because we haven't 
thought how to use Java better.

Think of tools like Hibernate and CForms.  Both store metadata in XML 
that can be captured in a Java object or in database metadata.  If we 
use Java 5 as the standard minimum JVM for Cocoon 3, we now have access 
to a couple nice features to enhance CForms.  Annotations are a powerful 
feature, and we should be looking for ways of using stock Java in new 
and better ways.  Why is Ruby on Rails fun to work with?  It is because 
things make sense.  You only need to learn Ruby to be able to create a 
useful website.  You don't need to learn Sitemap Markup Language, JEXL, 
CForms configuration language, Hibernate mapping language, Javascript, 
XML Stylesheet Language, and core configuration language.

There is a difference between configuration and convention.  Convention 
is the process of describing things by similarity.  Configuration is the 
process of describing things by difference.  Since we can only juggle so 
much at a time in our minds, guess which one wins?  I would venture to 
say that 90% of what goes in the Cocoon configuration file is 
untouched.  Why does there have to be a configuration item for it then?

I think what would be fun, and easier to learn for newbies, is to see 
just how much we can get Java to work _with_ the user instead of against 

View raw message