cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: [RT] Cocoon and web applications
Date Mon, 26 Feb 2001 21:53:24 GMT
Ok, I apologize in advance if this sounds harsh in any way. It isn't meant
to sound harsh. So, take everything I say with a grain of salt.



on 2/26/01 12:34 PM, "Berin Loritsch" <> wrote:

> Turbine is a specific framework.  There
> is nothing that says that Turbine can't be built on Avalon, nor is there
> anything that says that pieces of Turbine could be included in Avalon.

Yes there is. The fact that it would end up breaking a lot of people's code
and the fact that the configuration is entirely different between Turbine
and Avalon. Those are two MAJOR issues that no one here likes to even think
about. People just like to say that it can be done...but in reality, it
can't unless you want to also upset a lot of people.

Add to the fact that up until just recently (thanks to Sam's efforts),
Avalon has been a terrible moving target. Given that Turbine is enough of a
moving target itself (yes, it is often as bad as Avalon or worse),
compounding that with a dependency on another moving target would be
suicide. Note: Turbine has no official release. Therefore, the fact that it
is a moving target is ok due to the fact that it should only be used with
non-released-code disclaimers.

Solve those problems and I would be more than happy to have Turbine use
Avalon where it makes sense (I have been saying that for years now).
However, the fact of the matter is that I don't see it happening unless
someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
am not going to do it. What I have works just fine now and Avalon isn't my
itch. I don't need blocks, I don't need stuff componentized into a bazillion
pieces. I just need a web app framework.

> This has promise, although I would have to give some time to research
> the Turbine MVC patterns.  There is alot that could be learned here.

Nice to hear you say that given that the Action framework you just talked
about in Cocoon 2 is essentially something that was invented at least 4
years ago (even before Turbine existed) by my friend Leon Atkinson and was
done first in PHP! I find it humorous that this same Action framework is
also in Struts as well. More re-invention of the wheel because no one
bothers to look at Turbine first or people claim that Turbine isn't J2EE so
they don't want to use it. Duh. How lame.

> XSLT is a pain in the butt.

I can't agree more. It is more than just a pain in the butt, it SUCKS for
webapps. So far, the only cool XSLT application I have seen is Gump,
however, making modifications to the XSLT source code in Gump would give me
a headache.

> Where have you heard these critiques.  Everything I have read has been
> pretty much pro-Cocoon.  I mean Cocoon really excites the imagination
> of what can be done.  When you marry it with other less glamerous projects
> the result is a net boon for all projects involved.  It brings more
> users to the table for all of the technologies involved.

"Less glamorous [sic] projects"????????? Excuse me, I hope that you are not
referring to Turbine with that statement.

Combining all of our efforts together really is not a boon IMHO. The Turbine
project has been chugging along for over three years now and we have not
seen nearly the amount of political crap that other projects have been
seeing. No offense, but I don't want to bring that political crap into
Turbine at all and if someone did, I would personally flame them right off
the list. I would rather see us in Turbine land develop things more slowly
than have people messing up the Turbine project with political crap.

I have been asking for years now that the Cocoon people take a look at
Turbine, yet no one has bothered to do so. When people went gung-ho into
XSLT and Cocoon, I sat back and watched and waited. Now people figured out
that XSLT sucks even though I said XSLT sucked early on. What a joke.

Spend some time with Turbine and see how we do things before making ANY
further comments. Download the TDK and play with it. Try building a little
application. Please don't let me hear you saying that Turbine could be this
or that (even though you haven't even looked at it!) already is what it
is and that is good enough for quite a lot of people. Not everything has to
be J2EE or W3C or Jakarta-Combined-Library in order for it to be cool and do
the job extremely well (and often much better than the "standards" based way
of doing things).

Speaking of doing the job:

Turbine does ONE THING VERY NICELY. It allows you to build web applications
without having to constantly re-invent the wheel with commonly developed
code. Velocity does ONE THING VERY NICELY. It provides a nice template based
View/Controller part of the Model. Do you see a pattern there? No, I'm not
talking about a OO pattern (which is what Avalon and Cocoon tend to stick
with)...I'm talking about an overall design pattern.

Seeing projects like Cocoon trying to do a bazillion different things and
only being able to do an ok (not excellent, but not horribly bad) job of
each of those things (for example, Cocoon is great at output into a bunch of
different formats, but sucks for webapps). You can't build one tool that
solves every problem. For example, that is why there is "cp" and "mv" on
Unix...they each do one thing really well.

My vote is that if you really want to see Cocoon working with Turbine...or
you want to see Cocoon become a web application framework, then you should
figure out how to build that on top of Turbine instead of the other way
around. Turbine is not nearly as complex as Cocoon and it shouldn't be that
difficult given that Turbine already integrates a bazillion other tools.

p.s. There is no turbine-dev list or a java-apache-framework list and cross
posting across a bazillion lists is inconsiderate given that people won't
see the rest of the discussion.



If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<> && <>

View raw message