You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by allan li <al...@hotmail.com> on 2002/04/11 15:20:45 UTC
Cocoon & Struts
Hi everyone,
Could anybody give me some ideas about the comparison, relationships between
Cocoon2 and Struts, and how to use them together for a single web
application?
Thanks.
Alan
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
---------------------------------------------------------------------
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>
Re: Cocoon & Struts
Posted by Rob Jellinghaus <ro...@unrealities.com>.
At 09:20 AM 4/11/2002 -0400, allan li wrote:
>Hi everyone,
>
>Could anybody give me some ideas about the comparison, relationships
>between Cocoon2 and Struts, and how to use them together for a single web
>application?
Cocoon and Struts have a lot of overlapping functionality, but different
focuses.
Cocoon and Struts both seek to implement frameworks for web development
according, more or less, to the Model-View-Controller framework. The
breakdown, as I see it, is roughly as follows:
Model:
- Cocoon's models are XML-centric in that Cocoon generators (which
correspond more or less to the components responsible for pulling data from
the model) produce XML that represents the model's contents. XSP pages are
the main mechanism for doing so; XSP pages can source their data from the
servlet context, or from databases, or from Java objects, or what have you.
- Struts models are very Java-centric -- Struts tends to expect model
components to be Java business objects, which produce state that gets
stored in the servlet context (request, session, or application context),
or which are themselves directly accessible from the servlet context.
View:
- Cocoon has a very flexible framework for generating many possible views
of XML derived from a model. Cocoon supports pretty much anything you can
do with XSLT or other XML tools (Batik, etc.). It is very easy to do
complex things with XML in the Cocoon framework.
- Struts focuses mainly on JSP out of the box for view rendering -- the
default pattern with Struts is to use JSP to display content obtained from
(objects in) the servlet context. However, Struts can be used with servlet
chaining to hand off view responsibilities to other systems (there is work
underway to do so with Velocity). Struts itself does little or nothing
with XML or XSLT.
Controller:
- Cocoon has "Cocoon actions" which seem to have been latecomers to the
Cocoon design. Most of the current controller work in Cocoon is oriented
around the "Schecoon" scripting framework. This is very much a work in
progress.
- Struts is very controller-oriented, actually; Struts' entire
ActionMapping system is completely about the controller layer. Struts
makes it quite easy to get started building the logic of your website due
to its controller-centric design.
It is starting to look to me like it would be straightforwardly possible to
write some Cocoon XSP pages which expect to be fed from a Struts controller
system via servlet chaining. i.e. write your application logic in Struts,
and write your view structure in Cocoon, thereby using Struts to do the
controlling and Cocoon for the viewing. Cocoon is almost a bit overkill
for this, since it has so much more functionality than simply XML
transformation, but oddly it might wind up being easier to maintain this
kind of hybrid system than it would be to build the whole thing in either
Struts or Cocoon alone.
We shall see :-)
Cheers!
Rob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cocoon & Struts
Posted by Rob Jellinghaus <ro...@unrealities.com>.
At 09:20 AM 4/11/2002 -0400, allan li wrote:
>Hi everyone,
>
>Could anybody give me some ideas about the comparison, relationships
>between Cocoon2 and Struts, and how to use them together for a single web
>application?
Cocoon and Struts have a lot of overlapping functionality, but different
focuses.
Cocoon and Struts both seek to implement frameworks for web development
according, more or less, to the Model-View-Controller framework. The
breakdown, as I see it, is roughly as follows:
Model:
- Cocoon's models are XML-centric in that Cocoon generators (which
correspond more or less to the components responsible for pulling data from
the model) produce XML that represents the model's contents. XSP pages are
the main mechanism for doing so; XSP pages can source their data from the
servlet context, or from databases, or from Java objects, or what have you.
- Struts models are very Java-centric -- Struts tends to expect model
components to be Java business objects, which produce state that gets
stored in the servlet context (request, session, or application context),
or which are themselves directly accessible from the servlet context.
View:
- Cocoon has a very flexible framework for generating many possible views
of XML derived from a model. Cocoon supports pretty much anything you can
do with XSLT or other XML tools (Batik, etc.). It is very easy to do
complex things with XML in the Cocoon framework.
- Struts focuses mainly on JSP out of the box for view rendering -- the
default pattern with Struts is to use JSP to display content obtained from
(objects in) the servlet context. However, Struts can be used with servlet
chaining to hand off view responsibilities to other systems (there is work
underway to do so with Velocity). Struts itself does little or nothing
with XML or XSLT.
Controller:
- Cocoon has "Cocoon actions" which seem to have been latecomers to the
Cocoon design. Most of the current controller work in Cocoon is oriented
around the "Schecoon" scripting framework. This is very much a work in
progress.
- Struts is very controller-oriented, actually; Struts' entire
ActionMapping system is completely about the controller layer. Struts
makes it quite easy to get started building the logic of your website due
to its controller-centric design.
It is starting to look to me like it would be straightforwardly possible to
write some Cocoon XSP pages which expect to be fed from a Struts controller
system via servlet chaining. i.e. write your application logic in Struts,
and write your view structure in Cocoon, thereby using Struts to do the
controlling and Cocoon for the viewing. Cocoon is almost a bit overkill
for this, since it has so much more functionality than simply XML
transformation, but oddly it might wind up being easier to maintain this
kind of hybrid system than it would be to build the whole thing in either
Struts or Cocoon alone.
We shall see :-)
Cheers!
Rob
---------------------------------------------------------------------
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>