Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D06AA08.8020109@apache.org>
Date: Tue, 11 Jun 2002 21:55:20 -0400
From: "Andrew C. Oliver" <acoliver@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: We need a detailed comparison with Struts
References: <E9399342E12BD748B33EDEE4AD5A190B2817BD@king.flagship.ru>
 <3D05E539.6090209@anyware-tech.com> <3D061F5B.1050104@apache.org>
 <000801c21180$2fc745f0$56f313ac@kot>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

>
>
><quot>I hate writing JSPs and JSPs in general</quot> - you're not alone in
>this ;)
>  
>
What's funny is I've hated them from day one.  At one time I was like 
"well it sucks but what else is there and
out.print() in servlets sucks more"...  But now there are so many 
alternatives.

>JSP is somewhat integrated with Cocoon and the JSP samples are available at:
>http://localhost:8080/cocoon/samples/jsp/ , but I  don't think that it's the
>way to go, cause one of the frequent questions that I've seen in Struts
>Users list was: "How do I use XML/XSLT with Struts" and a little less often:
>"Can I use Struts with Cocoon".
>
>I don't think that there will be technical problems in Struts - Cocoon
>tandem, where Struts will be used a the front processor (controller) and
>Cocoon as the presentation layer. Struts is a rather simple servlet and can
>simply forward requests to Cocoon after input processing. But I'm quite sure
>that everything that can do Struts is possible with Cocoon too.
>  
>
Cool!

>  
>
>>>Good point here. But can't we make the assumption that the C2
>>>architecture is solid and will last a long time ?
>>>      
>>>
>>Thats a good question.  Can we?  Furthermore, when Cocoon moves on to
>>the next iteration of JAXP, what kind of
>>headaches will someone have deploying the upgrade?
>>    
>>
>
>I can't make such assumption. Cocoon is much more advanced than Struts, but
>moves very fast and sometimes in a backward incompatible way, while Struts'
>architecture (maybe because of its simplicity) is quit stable and the core
>does not change much.
>  
>
I on the other hand *can*.  The biggest pain is dealing with Tomcat -> 
Cocoon dependancy issues in a shared VM where
you don't necessarily have control of the classpath.  jaxp 1.0 may be in 
the classpath first.  Changing that may require (in
an larger organization) a massive moving of the beurocracy or a close 
relationship with a tight-lipped sysadmin.  If your
deadline is too tight for the first (or you just don't feel like it) and 
you don't have the latter...well you're screwed.

I would bet this is a pretty common situation in most large 
organizations.  So struts is infinitely more convienient than Cocoon.

I'm playing Devil's advocate here, when I have the choice, I'll pick 
Cocoon.  (see 
http://www.superlinksoftware.com/cocoon/samples/bringmethis/index.html)

>  
>
>>>      
>>>
>>yes, but this feeds into the marketing problem.  Just what IS Cocoon?
>>
>>    
>>
>
>This one will be solved when Cocoon Blocks are available and every
>installation can be customized depending on the needs and 3rd party stuff
>can be provided as blocks and not with the core.
>  
>
No.  It will be mitigated, but not solved.  Still answer "What is 
Cocoon?"  -- try it.

>  
>
>>>      
>>>
>>What does seperation of concerns (thanks for not abbreviating it) mean
>>to my boss?  (Yes I know what it means, but
>>its not a good high-level perspective.  MVC has caught on.  Many of the
>>paycheck signers don't know what it means but
>>they now know its something they should have...) -- and by the
>>way...sometimes I sell struts because its better than the
>>approach they have and Cocoon is way over their head or seems more
>>risky.  I'd still categorize cocoon as an emerging
>>technology.  Struts has nearly achieved "standard" level.
>>    
>>
>
>Though, our system architects understand either the MVC or the SoC very
>well, but the main reason that Cocoon was not choosed for our product is
>that Cocoon is really an emerging technologie and quite difficult to learn
>(most of our developers are good in JSP/Servlets, but they have never used
>neither XML nor XSLT, I don't even mention more advanced/complicated things,
>such as DTDs, Schemas, entity catalogs, XML namespaces, etc.).
>  
>
yes.

>  
>
>>(yes I think JSP sucks, I hate it, would far rather use Cocoon, but I've
>>yet to see case studies for high volume and availability
>>sites, I see XML-jar-hell as a big problem in some environments, etc,
>>etc -- so there are still situations that I'd use Struts for
>>instead of Cocoon).
>>    
>>
>
>So, to conclude, we need:
>    - better compatibility (J2EE compatibility)*)
>    - Cocoon blocks
>
           - This won't solve the "WHAT IS IT" problem.

>    - more stability in architecture
>    - more/better learning stuff: docs, tutorials, how-tos
>
thats a huge one.

>    - good show cases: success stories, real-life/demo applications
>  
>
yes, I'm working on that. The sample I'm working on 
(http://www.superlinksoftware.com/cocoon/samples/bringmethis/index.html) is
a rewrite of a live site (http://www.bringmethis.com) which will be 
converted and serve as a live of that.

>and I'd add also a more user friendly interface. Look at the Cocoon welcome
>page (/cocoon/welcome) - would you think from the first glance that it's a
>start page of a most innovative, advanced and best publishing system? ;)
>  
>
well here's the problem.  Struts is an MVC web application framework. 
 Well Cocoon is a......

>*)J2EE compatibility - this doesn't mean that we should better support JSP,
>though. We should allow JSP integration with Cocoon, but not support it very
>much, IMO. As I could see, the classloader problem was solved. Now the JAXP
>problem is next. Btw, Struts also uses JAXP, so Struts has similar problems
>on some app servers (I can say for sure about the IONA Orbix E2A App server,
>aka IONA iPortal).
>
Last time I used struts it used the same JAXP as the tomcat I was using. 
 First time I used Cocoon, it used a newer
version of JAXP than the version of tomcat I was using (renaming stuff 
zparser and the such).  While on my server and
any independant work I do, I use Tomcat 4.0x, at my *regular job* they 
use Tomcat 3.2.x still (my job there is not writing
software so..).  What's the point?  Well the upgrade curve.  I'll bet 
Cocoon will use JAXP 1.2 (or whatever) a long time before Struts will.

>--
>Konstantin
>
>P.S. I could speak infinitely about the pros and cons of Cocoon and Struts,
>but have to be back again to a JSP taglib specification writing :(
>  
>
Yes.... My sympathy.  Again...Struts is the right way to do the wrong 
thing, and Cocoon is the right way to do the right thing.
If the wrong thing is more common... okay sorry now I'm being depressing.

-Andy

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