cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivelin Ivanov <ive...@apache.org>
Subject Re: We need a detailed comparison with Struts
Date Thu, 13 Jun 2002 03:44:48 GMT
TREGAN Fabien wrote:
>>>Right, but this 3rd party stuff (in lib/optional) is for features that
>>
> Struts doesn't provide.
> 
>>yes, but this feeds into the marketing problem.  Just what IS Cocoon?
> 
> 
>   This is important : one of the main problem I hade when I said that wanted
> to use C2 for my project is that Cocoon defines itself as a "publication
> framework". The answer I hade was "we are not making a news portal, but a
> real application, we do not need to publish the content of our database in
> html, but to provide services with a web client".
>   So, when I hade to compare Cocoon with Struts (yes, I'm one of the 3
> Sylvain spoke about :), I tryed not to present Cocoon as a "publication
> framework" but as :
> -a MVC framework with text configured, extensible, controler
> -a framework that do not provide anything for the business tier (model) and
> oblige you to separate have a separated business tier (EJB, custom API) wich
> can provide XML
> -a pipe system based on XML and "transformers" for the view.
> -Avalon is great
> 
> So now how does it compare to Struts ?
> -Struts is a MVC Framework

So is XMLForm. Cocoon sitemap is far more sophisticated than 
struts-config.xml. Ovidiu's flow control is a working solution which 
delivers what Strut's workflow was planning to do but hasn't achieved 
yet. Plus with Creg's recent emails, it is now clear that Strut's 
development will most likely slow down quite a bit.

> -Struts don't oblige you bother with XML, but don't get real advantage of it
> -Struts leave it up to you to separate business and application tier, and
> JSP don't help you to separate logic and presentation.

Cocoon obliges you to use XML and thus separate logic, content and 
presentation.

> -If you can afford it, an application server is great
> 
> So :
> -Struts is faster to learn
> -(Struts should be faster to run, and use less memory, but we should test
> that, and use an EJB server or use Avalon in struts)
> -With struts, you can reuse all your javabean instead of loosing time to
> XMLize them

XMLForm does not XML-ize JavaBeans. Instead they're accessed directly, 
just like Struts does it. However a big advantage over Struts is that 
the "view" markup is client independent, based on XForms. This way 
styling and rendering forms is a lot more flexible than with Struts.
Remember that with Struts you can only write html forms. XMLForm allows 
you to write forms for HTML, WAP and other clients.

> -If you do not think XML is a must, if you do not want to separate logique
> from presentation, business from application, ok, use struts. I'll have warn
> you.
> 
> (maybe a more formal report when I have time to write it, but the important
> idea there is : Is Cocoon just a publication framework, or is it a Web
> Applicatioin Framework ?)


I think you could say that Struts used to be a publishing framework.
Starting with 2.1 it becomes a kick-a** web app platform.


Ivelin


>>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.
> 
> 
> Is there a "Software Engeneering for Dummys" book, I need one ? (for a
> "friend")
> 
> fabien.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



-- 

-= Ivelin =-


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


Mime
View raw message