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:[EMAIL PROTECTED]] > > Sent: Monday, June 10, 2002 12:24 PM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > 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. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
