cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaka Jaksic" <jaka.jak...@telemach.net>
Subject RE: [RT] Is Cocoon Obsolete?
Date Sun, 02 Oct 2005 01:41:31 GMT
Hi!

I am no Cocoon developer, but I have been working with it, together with my
team, since january, developing a real production application :). So having
written quite a large number of components (or are they services?) and
traced through the Cocoon code countless times, I think I might have
something to add to this discussion as well.

Geez, this is going to turn out as a very long post - please bear with me.

First I must say we're satisfied with Cocoon and with what it offers. But it
DOES cause MAJOR headaches, which IMHO it didn't have to.

Most problems probably stem from the fact that Cocoon was designed as a
publishing, not an application framework. However, I chose to use it for our
application, because of all web frameworks it best matched my former
philisophy and best practices for building web applications. Before, I
worked many years with Microsoft technologies and had no experience with
J2EE. So maybe I could have chosen a more suitable framework for our task,
but still I think the Cocoon philosophy is a good base for building even
complex web applications with lots of functionality and not just publishing.

However, in practice, it seems like as soon as you want to do things your
own way and not the Cocoon way's, you start hitting walls which you need to
cross with hacks and workarounds or by reinventing the wheel; walls being
mostly a consequence of its lack of flexibility. Okay, not everything can be
done with XML, that's understandable. But then, flowscript should have more
power. There is only this very simple object model (the "cocoon" object
etc.), which exposes very little of Cocoon's functionality. Okay, so you
need to write components. That's no big deal, because they're fun and easy
to write and the component system is one of the best things in Cocoon. But
even then you realize that accessing the natural functionality (and power)
of Cocoon is often very difficult, because there is no obvious API and no
function library to access the core functionality. For example, when you
need access to one particular piece of data or functionality (which you know
is *somewhere*), you often have to browse or step through countless classes
(don't forget, Cocoon has no small class library!) to find out where it is
being kept. And even then, after several hours of search, the sought for
object or method often turns out to be private and you can just go home and
cry. Or modify and rebuild the framework, which is something I don't believe
in.

So, I really think Cocoon needs to be made more developer-friendly. First,
it should be made more flexible by making its functionality more generic
rather than "Cocoon-way-specific". For example, why does each flowscript
call have to end with a sendPage? What if I don't want to "send a page" at
that moment and just want to set up some data for later use in the pipeline?
Also, by having to have a sendPage at the end of each flowscript execution,
you have to write many pipelines for a single request, even if it's actually
all just one logical pipeline, which makes the sitemap *EXTREMELY*
unreadable. I think forcing a sendPage at the end of a pipeline is
completely unnecessary. Why can't I just call a flowscript like an action?
Now I prefer writing actions instead of flowscript, because they are more
generic and don't impose any functionality I don't want.

As another example, why does the authentication action always have to
perform a redirect? I can perform the redirect myself if I want to, can't I?
I want the authentication component to just "let me in" if I am
authenticated, and if I am not, just continue and try to find another match
- in other words, behave just like a matcher. For this, I did exactly that:
create an authentication matcher (after hours wasted trying to get the
action do what I wanted - and nothing else!).

The next thing Cocoon needs is the already mentioned API. Cocoon has a lot
of great and very useful functionality, but it's all burried somewhere in
the huge pile of classes, which is very fustrating, because you can see it
work, but you can't use it yourself, your way. What I'm talking about are
functions for component management, pipeline set up and execution, cache
management, sitemap introspection, programatic access to dictionaries etc.
This is all very powerful and useful stuff, but now it's either use it the
Cocoon way or reinvent it. I'd like to be able to look up and use sitemap
components myself, programatically; set up and execute my own (dynamic)
pipelines programatically; manage cache programatically, and so on... And
also such an API would make Cocoon architecture itself much more clear.

The flexibility achieved this way would make Cocoon a great platform for
building web applications, and I think it would make it much more
attractive. And the best thing is, nothing needs to be done but a little
refactoring ;) Okay, this was a big joke, of course. I have no idea how
possible or feasible all this is, I'm just telling it would be great. But in
any way, during the development, you should always have other developers in
mind. Keep in mind that different people want to do things diffrent ways, so
you should keep everything as generic and as open for use and adaptation as
possible. And don't impose or hard-code functionality that is not necessary
for the given task.

Now, another bothersome thing about Cocoon is its complexity. Stripping it
to a minimum and documenting how to add what you need seems like a good idea
(probably better than having to have 50 megs of jars in your lib). Perhaps
an automatic dependency resolution...

But it's not just about the complexity of Cocoon as awhole, there's also the
complexity of its parts. Not everything is complex, of course, but some
parts are way too complex. Combine this with inflexibility and you've got
trouble. We just ditched CForms because of this and created our own forms
framework, which is much simpler and more flexible (not to mention
noticeably faster). It consists of about 5 (five) really simple classes (not
borrowing anything from CForms) and one quite simple XSLT, and it already
provides everything we need, including form definitions, validation and
binding. It doesn't require writing three separate files (+ flowscript) for
each form and allows mixing form content with HTML (and even executable
XSLT!). Okay, this our solution may be too simple and too specific for our
application to be used as a generic solution, but not necessarily. My main
point, however, is not to brag, but to point out that simple and extensible
solutions are more generally useful than complex ones with a ton of specific
functionality and a specific way of usage. If something does provide a lot
of specific functionality (which should only be a good thing), that
functionality should be built on top of a simple and extensible core
framework (and it should be documented what this core framework is and how
to use and extend it!). Only thit way the specific functionality can mean an
added value rather than a limitation! Cocoon's sitemap components model
(generators, transformers, serializers etc.) is a great example of
simplicity and extensibility. If only more of Cocoon was written that way...
But currently most of its functionality is way too tied together.

Oh yeah, and the sitemaps become too complex as soon as your solution
requires more than just a few typical generate-transform-serialize
pipelines. Splitting them into sitemaps doesn't help. What I'd like to have
is the ability to split sitemaps into several *files* (not subsitemaps!) and
bind them together with simple include operations. That way you could split
your sitemaps into smaller parts however you wished, and also share common
stuff between different sitemaps.

There, now I think I've said it all.

To sum it all up, I think Cocoon is far from obsolete, although it has
become a bit of a dinosaur. I think its future depends largely on its
developer-friendliness and adaptability (also keeping user docs up to date
with the class library would be nice). Adding new components, no matter how
useful, is going to do no good if developers can't find what they're looking
for and use it the way they want.

I'm keeping my fingers crossed...


Best regards,
Jaka Jaksic


Mime
View raw message