You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Todd Pierce <To...@hubbub.com.au> on 2003/02/05 01:36:27 UTC
[OT] RE: cocoon & struts together
Re the comment "Frameworks like struts mix functionality with
presentation...".
The presumption that functionality and presentation are mixed in Struts
needs qualification. Struts is an application framework. It's most valuable
component is the application layer. The presentation layer don't have to be
JSP/taglib. You can serve out xml for presentation if you wish, or (shudder)
even Flash.
Reasonable separation of functionality and presentation can be achieved
using any framework, if you follow 2 simple rules: Rule 1 - ensure that the
application layer does not generate any presentation. Rule 2 - ensure that
the presentation layer does not make any decisions. I use a tiles-based
template system, with screens defined in an XML doc, but y'know, what-ever.
I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon
and Struts, but not together. Cocoon for data delivery systems, because of
its fantastic separation of content and presentation, and Struts for
business applications simply because it's such a good application framework.
I don't believe either of these technologies should be considered to be a
panacaea for the ills of the web world.
-----Original Message-----
From: Robert Simmons [mailto:derisor@arcor.de]
Sent: Wednesday, 5 February 2003 10:43 AM
To: cocoon-users@xml.apache.org
Subject: Re: cocoon & struts together
Actually I'm an EJB specialist and I don't generally work on projects
conducive to web interfaces. The complexity level of the stuff I do is too
high. (Pharmaceutical industry and genetic research). My customers generally
require a higher range of functionality than a web interface can provide.
That being said, I do, however, do some web work which is why I took up the
idea of cocoon. I use the same technique that I use for GUI programming.
Basically a command centric architecture. I hate to say "struts is for
amateurs" but it kind of is. It has low complexity and thus low
functionality. It also has high cost in terms of content delivery and
maintenance costs. I personally chose to avoid all that and let Java objects
do all the work and let the framework just concentrate on presentation.
Enter
cocoon.
My programs consist of allot of specially designed generators that generate
pure data. Then I use XSLT to translate that into the appropriate media. I
also use XSLT to output the forms though I am experimenting with reflexive
techniques that I have used in GUI applications to make generation of forms
be based on reflexive command analysis.
Frameworks like struts mix functionality with presentation, which IMHO is a
very bad thing. Its a high maintenance cost solution with a low development
cost. That is the wrong way around. To be professional you want high
development cost and low maintenance cost. This causes your feature turn
around, post release, to be much faster. Since you are able to react quickly
to the demands of your users, your company or customers win. The guy that
slapped it together with low development costs may make some sales coming
out
the door, but will bleed customers as they seek more stable solutions with
faster turn-around time for new features and fault correction.
I guess that is a long way of saying, "put all your work into the back end."
Cocoon is perfect for this because you can develop custom generators to
deliver data and let a web designer with a couple weeks of training worry
about the XSLT translation. In the meantime your valuable programmer
resources are implementing new features and stabilizing the product.
Well that's my opinion on the matter.
-- Robert
----- Original Message -----
From: "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
To: <co...@xml.apache.org>
Sent: Tuesday, February 04, 2003 11:48 PM
Subject: Re: cocoon & struts together
> Robert Simmons dijo:
> > I dont think that using struts would be useful within an efficient
> > cocoon site. Cocoon takes another approach to web development that is,
> > in my opinion, superior to the jsp/struts approach.
>
> Thanks for the comment. I was trying to start learning about this stuff.
>
> As a bean specialist (a book writer) what tools you recommend to manage
> all the beans stuff (creation, changes, etc.)
>
> Thanks for the comments.
>
> Antonio Gallardo
>
>
>
> ---------------------------------------------------------------------
> 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>
>
---------------------------------------------------------------------
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>
---------------------------------------------------------------------
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: [OT] RE: cocoon & struts together
Posted by Robert Simmons <de...@arcor.de>.
I dislike CMP for a number of reasons. Not the least of which is that it is a
sledgehammer solution to put a thumbtack in a wall. The other reasons run a
wide spectrum and include things like lack of dynamic searches, inability to
convert objects to transient state and then back to persistent, the primary
key mechanism, having no access to the property methods and therefore not
being able to perform data validation and on and on. IMHO CMP = total
garbage. Its the one part of J2EE that is so poorly conceived that it should
just be torn out completely.
-- Robert
----- Original Message -----
From: "Ryan Hoegg" <rh...@isisnetworks.net>
To: <co...@xml.apache.org>
Sent: Wednesday, February 05, 2003 2:37 AM
Subject: Re: [OT] RE: cocoon & struts together
> Robert Simmons wrote:
>
> >My advice to you is to use EJB and J2EE on the back end, cocoon on the web
> >end, JDO for persistence and Swing for complex clients.
> >
> >-- Robert
> >
> After your previous comments I'm surprised you aren't pushing CMP 2 over
> JDO.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
> >
> >
>
>
> ---------------------------------------------------------------------
> 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>
>
---------------------------------------------------------------------
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: [OT] RE: cocoon & struts together
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Robert Simmons wrote:
>My advice to you is to use EJB and J2EE on the back end, cocoon on the web
>end, JDO for persistence and Swing for complex clients.
>
>-- Robert
>
After your previous comments I'm surprised you aren't pushing CMP 2 over
JDO.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
>
>
---------------------------------------------------------------------
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: [OT] RE: cocoon & struts together
Posted by Argyn <ak...@cox.net>.
Robert
Are we talking about the same Struts?
The Struts I know allows for a separation of logic and presentation.
Actually, its developers recommend not to mix logic into Struts components.
Struts is regarded as a "standard" Model2 (MVC a la J2EE) approach. So, you
have JSPs for views; Servlet Controller + Actions for control and
navigation. The logic is supposed to be out of Struts, it can be in EJBs,
e.g. In my current system, the logic will be in the set of API classes. Even
JSPs are not mandatory, it's just most people use Struts with them.
Finally, I'm afraid it's not appropriate to refer to other Apache projects
as "horrible" :) I'm a great fan of Cocoon too, but Struts is not bad, and
sometimes fits requirements very well.
thanks,
Argyn
-----Original Message-----
> From: Robert Simmons [mailto:derisor@arcor.de]
> Sent: Tuesday, February 04, 2003 4:49 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: [OT] RE: cocoon & struts together
>
>
> Struts is a horrible basis for business logic for a thousand reasons.
> Business logic best lives within an enterprise container and
> an application
> server. The basis of concurrency, fault tolerance,
> transaction management,
> clustering and the rest of the EJB contract make it pretty
> psycho to NOT use
> it. I would NEVER EVER do anything important in any web
> framework, be it
> cocoon or struts. No thanks the J2EE environment is the god
> of business logic
> as cocoon is, IMHO, the god of web presentation. Cocoon
> should be a CONSUMER
> of the J2EE functionality and not make any decisions whatsoever.
---------------------------------------------------------------------
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: [OT] RE: cocoon & struts together
Posted by Robert Simmons <de...@arcor.de>.
Struts is a horrible basis for business logic for a thousand reasons.
Business logic best lives within an enterprise container and an application
server. The basis of concurrency, fault tolerance, transaction management,
clustering and the rest of the EJB contract make it pretty psycho to NOT use
it. I would NEVER EVER do anything important in any web framework, be it
cocoon or struts. No thanks the J2EE environment is the god of business logic
as cocoon is, IMHO, the god of web presentation. Cocoon should be a CONSUMER
of the J2EE functionality and not make any decisions whatsoever.
Many people whip up some struts-JSP based applications, which basically
become servlets, and then pretend that the problems are solved. I could list
a thousand ways this paradigm is garbage, but I really don't have to because
other books do it quite well for me.
My advice to you is to use EJB and J2EE on the back end, cocoon on the web
end, JDO for persistence and Swing for complex clients.
-- Robert
----- Original Message -----
From: "Todd Pierce" <To...@hubbub.com.au>
To: <co...@xml.apache.org>
Sent: Wednesday, February 05, 2003 1:36 AM
Subject: [OT] RE: cocoon & struts together
> Re the comment "Frameworks like struts mix functionality with
> presentation...".
>
> The presumption that functionality and presentation are mixed in Struts
> needs qualification. Struts is an application framework. It's most valuable
> component is the application layer. The presentation layer don't have to be
> JSP/taglib. You can serve out xml for presentation if you wish, or
(shudder)
> even Flash.
>
> Reasonable separation of functionality and presentation can be achieved
> using any framework, if you follow 2 simple rules: Rule 1 - ensure that the
> application layer does not generate any presentation. Rule 2 - ensure that
> the presentation layer does not make any decisions. I use a tiles-based
> template system, with screens defined in an XML doc, but y'know, what-ever.
>
> I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon
> and Struts, but not together. Cocoon for data delivery systems, because of
> its fantastic separation of content and presentation, and Struts for
> business applications simply because it's such a good application
framework.
> I don't believe either of these technologies should be considered to be a
> panacaea for the ills of the web world.
>
> -----Original Message-----
> From: Robert Simmons [mailto:derisor@arcor.de]
> Sent: Wednesday, 5 February 2003 10:43 AM
> To: cocoon-users@xml.apache.org
> Subject: Re: cocoon & struts together
>
>
> Actually I'm an EJB specialist and I don't generally work on projects
> conducive to web interfaces. The complexity level of the stuff I do is too
> high. (Pharmaceutical industry and genetic research). My customers
generally
> require a higher range of functionality than a web interface can provide.
>
> That being said, I do, however, do some web work which is why I took up the
> idea of cocoon. I use the same technique that I use for GUI programming.
> Basically a command centric architecture. I hate to say "struts is for
> amateurs" but it kind of is. It has low complexity and thus low
> functionality. It also has high cost in terms of content delivery and
> maintenance costs. I personally chose to avoid all that and let Java
objects
> do all the work and let the framework just concentrate on presentation.
> Enter
> cocoon.
>
> My programs consist of allot of specially designed generators that generate
> pure data. Then I use XSLT to translate that into the appropriate media. I
> also use XSLT to output the forms though I am experimenting with reflexive
> techniques that I have used in GUI applications to make generation of forms
> be based on reflexive command analysis.
>
> Frameworks like struts mix functionality with presentation, which IMHO is a
> very bad thing. Its a high maintenance cost solution with a low development
> cost. That is the wrong way around. To be professional you want high
> development cost and low maintenance cost. This causes your feature turn
> around, post release, to be much faster. Since you are able to react
quickly
> to the demands of your users, your company or customers win. The guy that
> slapped it together with low development costs may make some sales coming
> out
> the door, but will bleed customers as they seek more stable solutions with
> faster turn-around time for new features and fault correction.
>
> I guess that is a long way of saying, "put all your work into the back
end."
> Cocoon is perfect for this because you can develop custom generators to
> deliver data and let a web designer with a couple weeks of training worry
> about the XSLT translation. In the meantime your valuable programmer
> resources are implementing new features and stabilizing the product.
>
> Well that's my opinion on the matter.
>
> -- Robert
>
>
> ----- Original Message -----
> From: "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
> To: <co...@xml.apache.org>
> Sent: Tuesday, February 04, 2003 11:48 PM
> Subject: Re: cocoon & struts together
>
>
> > Robert Simmons dijo:
> > > I dont think that using struts would be useful within an efficient
> > > cocoon site. Cocoon takes another approach to web development that is,
> > > in my opinion, superior to the jsp/struts approach.
> >
> > Thanks for the comment. I was trying to start learning about this stuff.
> >
> > As a bean specialist (a book writer) what tools you recommend to manage
> > all the beans stuff (creation, changes, etc.)
> >
> > Thanks for the comments.
> >
> > Antonio Gallardo
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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>
> >
>
>
> ---------------------------------------------------------------------
> 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>
>
> ---------------------------------------------------------------------
> 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>
>
---------------------------------------------------------------------
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>