Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Reply-To: <bloritsch@apache.org>
From: "Berin Loritsch" <bloritsch@apache.org>
To: <cocoon-dev@xml.apache.org>
Subject: [RT] Cocoon Integration Model
Date: Mon, 15 Jul 2002 10:12:43 -0400
Message-ID: <009101c22c09$afd93250$ac00a8c0@Gabriel>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal

Something that has been bothering me regarding Cocoon's web app model is
how the webapp is supposed to be defined.  Cocoon started as a content
publishing model.  At this, it is better than anything else out there.
Using Cocoon for webapps has traditionally been troublesome.  As a
result,
we have been trying to extend it and make it a better platform for web
applications.

The ways we extended it made it closer to an ideal, but never quite
there.
The J2EE blueprints, struts, and turbine all advocate an MVC approach.
We have been trying to make that happen in Cocoon as well.  We have MVC
for the presentation of information--model=XML,
view=transformes/serializers,
and controller=sitemap/actions.  However, that is not the proper
division
for a web Application.

* A proper model represents the application data.  Whether you use
direct
  SQL manipulation or an object model is up to you.  XMLDBs attempt to
  represent the data in XML--which seems the best way for Cocoon.
However,
  XMLDBs are largely unproven in high transaction environments so
traditional
  shops want to opt for more traditional models.

* Cocoon itself is the ultimate view.  You can represent your
information
  in so many different formats it isn't even funny.  According to J2EE,
  Servlets and JSPs are types of *views*.  Essentially, this makes
Cocoon
  as a whole just another view.

* Control is a more complex subject as different types of control work
  together to represent a coherent application.  The J2EE blueprints
have
  Session EJBs handle the application logic, while the servlets handle
  the presentation logic.  It is important to separate them out because
  handling which page of a form comes next is different from what
happens
  when we approve something.  Cocoon works well for presentation logic,
  but admittedly does not do well for application logic.

As a result, what we have now to overcome the basic deficiencies in the
Cocoon integration picture is the inclusion of Transformers, Generators
(XSP esp.), and Actions that all perform application level logic.  The
two biggest culprits are the Action and the Generator.

I have developed a few webapps using Cocoon, and have boiled down how
to come up with a Quick and Dirty (Q&D) setup rather quickly.  However,
I have never been satisfied with what it takes to bring other developers
on board.  By the shear quantity of information, component types, and
now pipeline types, the average newbie spends much longer trying to
understand Cocoon than they do actually using it.

When I wrote the first cut of the webapp tutorial, I had every intention
of making it as useful as the "Developing with Avalon" document I wrote.
Unfortunately, I ran out of time.  My arguments about Cocoon apps being
easier to maintain and supporting simultaneous development went out the
window when people I was working with in my office spent six weeks
trying
to come to grips with everything.

I tried to tell them that if you use the markup I developed everything
would look like it belonged to the site.  I still had one stubborn
developer
who insisted on directly writing broken HTML.  I tried to tell them that
they didn't have to worry about the sitemap--it was my responsibility,
but still they tried to understand it.

It can be argued that the troubles I had were largely due to training
or management decisions.  (Once I got a developer working with it
properly, she and I cranked out the application in about two weeks).
The problem is more fundamental than that.  The problem is that there
is no proven or set way of creating web applications using Cocoon time
after time after time.  That is what the J2EE blueprints are for.  To
help developers not waste their time on harmful patterns, and
concentrate
on more useful aspects of J2EE.  As a result, it is a platform that
works--maybe not the best, but it works.

Cocoon can definitely use its own blueprint.  A Cocoon Application
Blueprint is an essential document that we need.  There are two ways
of using Cocoon: integrated in with a traditional J2EE environment,
and standalone.  The blueprint will define exactly what part of the
puzzle Cocoon supports.  It will also define which patterns work well,
why they work well, and the antipatterns which suck all your time.

A side-affect, and general improvement will be that Cocoon will begin
to be shaped by the blueprint.  The proposals that are given will be
there to enhance the model, or to overcome shortcomings.  As we state
*how* Cocoon should be used, it's development effort will follow that
pattern.  As of right now, the oppinions on how to get the best out
of Cocoon are as varied as the number of developers on the list.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


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