You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/06/10 10:23:50 UTC
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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: We need a detailed comparison with Struts (XML/REST integration?)
Posted by Ivelin Ivanov <iv...@apache.org>.
As long as Struts is concerned, Cocoon 2.1 includes the XMLForm
components, which takes a lot of Struts' ideas.
XMLForm was designed from the ground up for REST style web services.
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html
If you want to contribute a comparison document, I'll welcome it. ;)
Ivelin
Bertrand Delacretaz wrote:
> On Monday 10 June 2002 10:23, Sylvain Wallez wrote:
>
>>. . .
>>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) ?
>>. . .
>
>
> Rings a bell here, cause I'm thinking along the same lines between Enhydra
> (www.enhydra.org) and Cocoon.
>
> How about using these (struts, enhydra, etc.) as XML-based back-ends to a
> Cocoon presentation front-end?
>
> I'm thinking of Cocoon relaying user HTTP requests to the back-end, and the
> back-end replying with XML documents representing the "logical contents" of
> pages (see also [1]).
>
> The back-end would be fully testable with anteater, JUnit/HTTPUnit or
> something using HTTP/XML interactions, and the Cocoon front-end would be
> nicely decoupled and care only about the presentation layer.
>
> Any comments? First-hand experiences?
>
> -Bertrand
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
--
-= Ivelin =-
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: We need a detailed comparison with Struts (XML/REST integration?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 10 June 2002 10:23, Sylvain Wallez wrote:
>. . .
> 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) ?
>. . .
Rings a bell here, cause I'm thinking along the same lines between Enhydra
(www.enhydra.org) and Cocoon.
How about using these (struts, enhydra, etc.) as XML-based back-ends to a
Cocoon presentation front-end?
I'm thinking of Cocoon relaying user HTTP requests to the back-end, and the
back-end replying with XML documents representing the "logical contents" of
pages (see also [1]).
The back-end would be fully testable with anteater, JUnit/HTTPUnit or
something using HTTP/XML interactions, and the Cocoon front-end would be
nicely decoupled and care only about the presentation layer.
Any comments? First-hand experiences?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: We need a detailed comparison with Struts
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ivelin Ivanov wrote:
>
> Sylvain,
>
> I had asked this question myself about 6 months ago.
> A few things happened since then, and Cocoon now has a new component:
> XMLForm. It tightly integrades with Cocoon and provides all features
> of Struts which I am aware of or at least I ever used.
I only had a quick look at it and had the same impression. This is good.
> Your document will be a valuable contribution. Please try to keep it
> factual so that it does not trigger any negative cross project
> reactions. Taking a few typical problems usually solved with Struts
> and showing how they can be solved with XMLForm would be a good approach.
That's exactly how I want it to be. Struts being also an Apache
projects, we should not start a war between projects, but show how
Cocoon compares with Struts to people that may not have a real knowldege
of either, but hear more often the "Struts" buzzword.
> Struts is a very successful MVC framework. It works great for
> applications based on JSP.
> XMLForm was designed from the ground up to be a native part of Cocoon,
> which separates form content from presentation and allows reuse for
> REST style Web Services.
>
>
> An experienced Struts developer will be able to answer many of the
> questions you pose by looking at the XMLForm HOWTO.
> http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html
Any experienced Struts developper out there that can give his/her
opinion on this ?
Thanks,
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: We need a detailed comparison with Struts
Posted by Ivelin Ivanov <iv...@apache.org>.
Sylvain,
I had asked this question myself about 6 months ago.
A few things happened since then, and Cocoon now has a new component:
XMLForm. It tightly integrades with Cocoon and provides all features of
Struts which I am aware of or at least I ever used.
Your document will be a valuable contribution. Please try to keep it
factual so that it does not trigger any negative cross project
reactions. Taking a few typical problems usually solved with Struts and
showing how they can be solved with XMLForm would be a good approach.
Struts is a very successful MVC framework. It works great for
applications based on JSP.
XMLForm was designed from the ground up to be a native part of Cocoon,
which separates form content from presentation and allows reuse for REST
style Web Services.
An experienced Struts developer will be able to answer many of the
questions you pose by looking at the XMLForm HOWTO.
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html
Regards,
Ivelin
Sylvain Wallez wrote:
> 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
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: We need a detailed comparison with Struts (XML/REST integration?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 10 June 2002 10:23, Sylvain Wallez wrote:
>. . .
> 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) ?
>. . .
Rings a bell here, cause I'm thinking along the same lines between Enhydra
(www.enhydra.org) and Cocoon.
How about using these (struts, enhydra, etc.) as XML-based back-ends to a
Cocoon presentation front-end?
I'm thinking of Cocoon relaying user HTTP requests to the back-end, and the
back-end replying with XML documents representing the "logical contents" of
pages (see also [1]).
The back-end would be fully testable with anteater, JUnit/HTTPUnit or
something using HTTP/XML interactions, and the Cocoon front-end would be
nicely decoupled and care only about the presentation layer.
Any comments? First-hand experiences?
-Bertrand
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>