cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Collen <colle...@umn.edu>
Subject Re: [RT] Is Cocoon Obsolete?
Date Fri, 30 Sep 2005 23:48:10 GMT
Stefano Mazzocchi wrote:

<snip/>
> If you ask me, the current infatuation with Ruby on Rails and friends, 
> while understanding and to the point (the need to avoid XML pushups, 
> so true), will fail dramatically short in scale to complex systems. 
> Just like M$ Word is great to write one/two pages and it fails 
> miserably to help you with your thesis, something like rails is 
> awesome for your blog or single-handed ecommerce web site, it would 
> kill you no less than PHP with a massively complex web site.
>
<snip/>
> How do you feel about this?
I have a couple thoughts on this.  Actually it's more of a brain dump. ;)

1.  (Like Berin) I am admittedly infatuated with Rails.  This may be the 
infatuation speaking, but the "Rails doesn't scale" smells like FUD to 
me.  I'm still infatuated with Cocoon, too, BTW.  I've been building 
Struts apps for the past 6 months and I am constantly cursing JSP. JSTL, 
taglibs, etc. (see #2B, below).  I can't wait to /stop/ building Struts 
apps, but my dislike for Struts may pollute my opinion of JSF when the 
company I work for eventually decides to move in that direction.

1A. Stuff I've done in Rails I have liked, but was always sort of 
wishing for more "Cocoonish" -- Flowscript, Sitemaps, etc. Ruby has 
native continuations, so there might still be hope.  One thing I was 
trying to do that's very simple in Cocoon (or HTTPD for that matter) is 
something like this:

<map:match pattern="docs/**/*">
  <map:generate src="xml/{1}/{2}.xml"/>
  <!-- whatever else -->
  <map:serialize />
</map:match>

In Rails, you have to setup some sort of "TemplateController", manually 
inspect the request path, parse it out, and then send the file on the 
local disk as text/html.  I think part of this stems from the fact that 
Rails is more of a webapp framework than a publishing framework (where 
obviously the opposite was true for Cocoon for quite a while).   In this 
sense, Rails still has some maturing to do.  Likewise, Rails' 
ActiveRecord covers probably 80% of the use cases for building webapps.
 
2.  In the 4-or-so years I've been involved with the community, I've 
*never* built a production website with Cocoon, and I highly doubt I 
ever will.  It hasn't caught on here in the states as much as Struts 
has, or JSF could.  I was holding out hope for a Cocoon type job, but as 
soon as I graduated University and needed a job, all of the J2EE jobs 
were Struts-based, and Spring is *just* starting emerge as something 
companies are investing in.  See #4, below for more thoughts.

2B) I've seen some stuff at work where I have said, "Cocoon does this," 
but Struts didn't, so it was implemented (poorly) in Struts, causing all 
sorts of headaches.

2C) The only reason I have a job however, is because of all the exposure 
to *other* J2EE stuff that Cocoon got me into.  Maybe I should have 
moved to Belgium ;)

3. More functionality is moving to the browser, but the apps will still 
reside on servers. I can't see that moving away.  I always knew 
server-side XSLT was sort of a stopgap until browsers could do it reliably.

4. I have to agree with Berin's point about convention and 
simplification over configuration.  With things like Spring, and books 
like _Better, Faster, Lighter Java_ (and XP themes in general), there's 
a move to make things easier to understand, maintain, and be concise at 
the same time.  IMO Rails hits these points pretty nicely, not only 
because Ruby is a concise, elegant language, but you also get a lot of 
"Good practices" for free.  You get the separation between development, 
test, and production environments/databases.  You get a lot of unit and 
functional testing for free when you generate your code.  You can even 
get webapp controller tests for free, which is more than I can say about 
Cocoon.  And the free stuff goes a long way.

In conclusion, I don't think Cocoon "The Idea" is obsolete, but perhaps 
Cocoon "The Implementation" is.  Here's where I put on my "I have a 
bunch of good ideas but none of the skill to implement them" hat:

 - Simplify Cocoon.  What's the bare minimum we can get away with?   Not 
only functionality, but also actual amount of code?  Ugo's work with 
Spring and Butterfly probably is a good starting point.

- Borrowing another buzzword, how can we move Cocoon "The Idea" into the 
Web 2.0 era?  I really hated to invoke it, but I think it's important.  
I'm not necessarily talking about how we can make Cocoon serve "Web 2.0" 
apps, but more along the ideas of Better, Faster, Lighter.  Maybe I'm 
mixing my ideas of Web 2.0 and "better Java development practices" here.

----
Tony, who feels like he dumped a lot of stuff from his brain because of 
Stefano's RT.

Mime
View raw message