cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: We need a detailed comparison with Struts
Date Mon, 10 Jun 2002 12:30:00 GMT
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:

	- Cocoon has portability problems while JSP is supported natively by
many/several App Servers and some of them have Struts already integrated
	- XSP is not standart while JSP has a specification, compatibility
tests, etc.
	- JSP is much more popular than XSP and there is a lot of general
purpose JSP taglibs available
	- Cocoon changes to quick - we had a lot of problems with C1->C2 and
that experience frightened our architects
	- Cocoon's codebase is much more complicated than Struts' and
depends/uses a lot of 3rd party stuff
	- 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.
	- and at last, not every application needs multimedia output that is
one of the coolest features of Cocoon

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.

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.

Regards,
  Konstantin

P.S. I'll send a more detailed answer to the list if time allows and will
answer all the listed questions. 

_________________________________________
Konstantin Piroumian
Lead Developer
ICQ#: 2297575
* Work Tel#:  +7 095 795 0520 * 1288
* More ways to contact me
i See more about me
_________________________________________



> -----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.
> 
> 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 ?
> 2 - what does Struts do that Cocoon can't ?
> 3 - what does Cocoon do that Struts can't ?
> 4 - can we integrate Struts and Cocoon ?
> 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.
> 
> 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.
> 
> Struts also offers internationalization features that are 
> fullfilled by 
> Cocoon's I18N transformer and locale management.
> 
> 
> 2 - what does Struts do that Cocoon can't ?
> -------------------------------------------
> Mmmh... got an idea, someone ? ;)
> 
> 
> 3 - What does Cocoon do that Struts can't ?
> -------------------------------------------
> Struts in intrinsically limited to what can be done with 
> JSPs, which is 
> producing text output such as HTML or WML. Moreover, it's JSP 
> taglib is 
> very tied to HTML.
> 
> Cocoon, on the other hand, has a flexible serializer mechanism that 
> allows it to produce any kind of output such as (but not limited to) 
> PDF, JPEG, RTF.
> 
> The flow engine in Cocoon (in 2.1), by using a real 
> programming language 
> and continuations (the ability to suspend a program), is far more 
> powerful than the action mapping definition in Struts.
> 
> Finally, Cocoon offers a very flexible and extensible 
> framework that can 
> integrate almost anything, and comes with a lot of features 
> that aren't 
> built into Struts. To name a few : browser selector, flexible form 
> validation, database manipulation actions and XSP taglibs (add other 
> important features here).
> 
> 
> 4 - Can we integrate Stuts and Cocoon ?
> --------------------------------------
> The JSP part of Struts can certainly be integrated into 
> Cocoon using the 
> JSPGenerator. What about the controller part (i.e. the servlets) ?
> 
> 
> 
> Thanks for your input,
> Sylvain
> 
> -- 
> Sylvain Wallez
>   Anyware Technologies                  Apache Cocoon
>   http://www.anyware-tech.com           mailto:sylvain@apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
> 

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


Mime
View raw message