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 18:08:39 GMT
Berin Loritsch wrote:
> 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.

Have a look at the top of : "Perfection is achieved 
not when there's nothing more to add, but when there's nothing left to 

> 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.

You can't assume that: Cocoon is also one of the very few frameworks 
that allows people with little programming knowledge to do some 
non-trivial stuff, and we should not loose this goal. That's why I 
consider keeping JavaScript as a glue language something important.

> 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.

I've been giving another Cocoon training this week, and you cannot know 
how each time people are amazed by the power of Cocoon, but frightened 
by the number of things they have to learn.

> 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?

And that's even worse: if you look at cocoon.xconf, most of the 
configuration that's there is the built-in default, but is put there as 
an example of what can be done. The result is a scary file that regular 
people modify with the "what will I break this time" fear in mind.

> 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 them.



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

View raw message