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