cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: We need a detailed comparison with Struts
Date Mon, 10 Jun 2002 13:03:54 GMT
some additions/comments inline.

>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
>
and may will probably have Cocoon before long.

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

>	- JSP is much more popular than XSP and there is a lot of general
>purpose JSP taglibs available
>
Just a thought....it seems possible to do a XSP-JSP taglib compatibility 
layer.  The syntax would be a bit
different of course, but I think it could be done.

>	- 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
>  
>
I don't agree with the last one.

add:

- Cocoon is inadequately documented
- The Cocoon community is from the "pattern hell" school of thought.
- Describing Struts to other prospective users can be done without using 
any three letter abbreviations other than JSP.
     - its not possible to explain Cocoon without close to 50 three 
letter abbreviations that no one outside of Cocoon and/or
     - not intimately familiar with XML knows.
- Cocoon is percieved as way more heavyweight and poorly performing 
(Which I don't find to be the case necessarily)
- XSLT is harder than JSP.

>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.
>  
>
yes... . XML-parser-hell...welcome to my world.

>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
>
>
>  
>




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


Mime
View raw message