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 http://bluxte.net : "Perfection is achieved
not when there's nothing more to add, but when there's nothing left to
remove."
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.
Yup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
