cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: We need a detailed comparison with Struts
Date Wed, 12 Jun 2002 21:06:15 GMT
Piroumian Konstantin wrote:
> 
> Hi!
> 
> I have alsmost 2 years' experience in the XML (Cocoon) vs. JSP (Struts)
> fight in our company, wrote several documents related to
> Cocoon/Struts/Self-implemented framework comparison and I'd like to tell
> that all the arguments for Cocoon break on the following:

I think this calls for some answers.
 
>         - Cocoon has portability problems while JSP is supported natively by
> many/several App Servers and some of them have Struts already integrated

I never heard of this. Can you please indicate what are those
'portability problems' you have experienced? (you or the people you
talked to)

>         - XSP is not standart while JSP has a specification, compatibility
> tests, etc.

Granted.

>         - JSP is much more popular than XSP and there is a lot of general
> purpose JSP taglibs available

Granted.

>         - Cocoon changes to quick - we had a lot of problems with C1->C2 and
> that experience frightened our architects

Granted. I'm personally aware of the fact that many people got seriously
hurt by this migration. At the same time, Cocoon1 had too many design
issues and there was no way around this.

At the same time, the Cocoon dev community learned a lot of lessons and
if somebody believes this is going to happen again (with books coming
out of the door) they are simply underestimating the amount of money
that several companies/organizations are investing in Cocoon (think NASA
and you know what I'm talking about)

>         - Cocoon's codebase is much more complicated than Struts' and
> depends/uses a lot of 3rd party stuff

Granted.

>         - Cocoon requires knowledge of many different technologies/things
> (Java/Servlets, XML, XSLT, XSP, Sitemap, JavaScript - for flow, and some
> others, optionally) while Struts is much simpler in usage and requires
> knowledge only of JSP/Servlets and has a relatively simple configuration
> file in XML.

Absolutely.

>         - and at last, not every application needs multimedia output that is
> one of the coolest features of Cocoon

That's for sure.
 
> The above is not my personal opinion, but was gathered in a lot of
> discussions with my collegues and our experience either with Cocoon or
> Struts.

Ok
 
> My personal opinion is that if Cocoon had no compatibility problems (usually
> those are JAXP and classloader problems and rarely problems come from
> Cocoon's request/response abstractions) then it would be much better for any
> middle/high level of complexity web applications than Struts.

I feel that Cocoon is still way too weak from the flow description
perspective in order to seriously compete with any web-app oriented
frameworks.

Cocoon is and remains focused on publishing (that is: declarative web
serving) until we have a way to describe procedural flows. See more
below.

> > -----Original Message-----
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > Sent: Monday, June 10, 2002 12:24 PM
> > To: cocoon-users@xml.apache.org; cocoon-dev@xml.apache.org
> > Subject: We need a detailed comparison with Struts
> >
> >
> > Hi folks,
> >
> > In less than 10 days, (potential) customers asked "how does Cocoon
> > compare to Struts and JSP ?" This isn't the first time this
> > question is
> > asked, but it's becoming more and more frequent. So in turn I ask you
> > this question, since my knowledge of Struts is limited to the docs at
> > the Jakarta site.
> >
> > My impression is that Struts is targetted at web applications
> > (opposed
> > to content publication) in HTML (no PDF, SVG, WML) and that
> > Cocoon has
> > equivalent components (form validation stuff, actions, some
> > XSP taglibs)
> > but can do much, much more.

Absolutely. The problem is: Cocoon can do more than Struts, but what
Struts does (or Turbine, for that matter) is highly focused on something
that Cocoon is not really good at (YET!): managing and describing a way
to build states and transitions (what they wrongly call "MVC")

> > The aim of this discussion not to start a Cocoon vs Struts
> > flame, but to
> > build a document that will go into Cocoon docs to help us to promote
> > Cocoon when such questions arise.
> >
> > The points to address are :
> > 1 - how does Cocoon implement Struts features ?

IMHO, very poorly until we make the flowmap implementation seemlessly
integrated in the Cocoon design (and samples!)

[yes, I know it's working, but it's not as 'seemlessly integrated' as I
would like it to be... expect a few RT from me on this in the very close
future]

> > 2 - what does Struts do that Cocoon can't ?

today, in order for Cocoon to match Struts capabilities, you have to go
thru the hoops of writing a bunch of Actions. The try/fail cycle is
horribly slow. A pain.

If you look at a bunch of those complex samples we have in CVS (XMLForm,
Authentication, Portal, ...) they all have their web-app logic included
in some actions that were crafted exactly for this.

I never wrote anything in Struts, but I seriously doubt this can be
worse than what we have today with Actions.

Now, this might give you the impressions that Cocoon is inherently poor
for web-app building: no way! that's not the case, we are simply missing
the balance betweeen declerative serving (in which cocoon clearly
excels) and procedural serving (in which Cocoon is extremely poor).
Struts and Turbine do the other way around.

Their problem is: they don't know, but we do. :)

So, if you have a million pages that you have to publish in PDF, don't
use Struts, that's no brainer. But what if those million pages need to
be edited using a DHTML-based client-side editor passing thru a workflow
*AND* need to be published in PDF?

In that case, you need *BOTH* capabilities: declerative serving (for the
PDF stuff, mostly GET-based stateless requests) *and* procedural serving
(for the web-app flow, mostly GET-POST statefull roundtrips of
requests).

The sitemap was clearly defined for declarative serving. It's great at
that.

But Actions (a concept we admittedly stole from Turbine) were
implemented to allow some procedural logic to be placed inside the
pipelines.

Result? a mess. The intrinsic reusability of an action is much less than
any other cocoon sitemap component. This should ring a bell about the
fact that actions don't belong there.

So what? flowmap. Every logic that doesn't deal with an XML stream
should be placed in a flow description language. We choose javascript
because it's easier to learn, to write and to use than any markup
language (and it's so close to java that you don't even notice the
difference).

Add continuations to the mix and I seriously think we can beat the crap
out of *any* other framework that's out there.

> > 3 - what does Cocoon do that Struts can't ?

well, the list is simply too big :)

> > 4 - can we integrate Struts and Cocoon ?

I seriously hope this is not even tried: after the flowmap is finished,
I think the effort required to write a cocoon web application will be
order of magnitude easier than with any JSP-based approach.

And, yes, you can quote me for that.

> > 5 - other items ?
> >
> >
> > Here's my view on these items :
> >
> > 1 - how does Cocoon implement Struts features ?
> > -----------------------------------------------
> > The main purpose of Struts is to provide a MVC framework in
> > JSP. MVC is
> > about separating application concerns, which is something that is
> > naturally built in and enforced by Cocoon.

MVC is *ONE* way of separating concerns. Cocoon is more flexible: it was
designed around concept so allows you to choose your way of doing SoC.
This is a big difference.

> > In Cocoon, the model is some presentation-independent XML produced by
> > generators from almost any kind of source (database, beans, EJB, xml
> > files, etc.), the view is defined by the transformation pipeline (XSL
> > stylsheets, I18N transformer, etc), and the controller is defined by
> > actions. Form validation and flow engine implement the equivalent
> > features in Struts.

Bah, I'm pretty sure that everybody here has a different mapping for
what is a view/controller or model in Cocoon. moreover: I don't think
why we should be using a design patter that was build for GUI
applications (what didn't have any distribution or statefull problem)
for the web.

Anyway, instead of wasting time trying to integrate Struts and Cocoon
(or Turbine and Cocoon), I'll spend time trying to get the flowmap
infrastructure finished the way I like it.

So that everyone can draw their own conclusions afterwords.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message