You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Matthew Hailstone <ma...@waterford.org> on 2002/05/22 22:19:20 UTC

Cocoon and Enhydra

I've been a newbie with Cocoon for about 1 month now. My accomplishment
at slaughtering all the buzz words in the following will probably be
evident.
Some suggestions would be nice. Thanks in advance. :)
 
Enhydra Pros
 
Established API that allows interaction with DOM.
Precompile classes for performance.
Follow MVC (Model 2) by establishing a common value of the "id"
attribute in elements and letting the web graphic/presentation designers
have at it.
 
 
Cocoon Pros
 
MVC architecture with sitemap controlling the business logic, generators
handling data logic, transformers and serializers performing the
presentation layer.
Uses well established specifications as its core (Java Servlet API, XML,
XSL).
 
 
Enhydra Cons
 
<The following taken from
http://jakarta.apache.org/velocity/casestudy2.html>
Designer designs the page and then engineer puts in the logic.
Employing engineers to do everything in the first place.
ie. (What happens when a designer incorrectly enters id's in the page?
All of the engineers code becomes unusable. Now that's a nice separation
between presentation and functionality)
<Now I understand the mistakes are inevitable, but how much merit does
the above have?>
I think the biggest problem XMLC, JSP and servlets are facing is more a
philosophical nature: the document is data, not code.
<What is meant by "the document"?>
Why would you convert your HTML into a Java class when you want to send
it to the browser as text?
 
 
Cocoon Cons
 
Learn XSL and XSLT syntax
Decrease in performance due to transformation handling. (Enhydra is
precompiled everything.)