cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [DAISY] Created: Vision
Date Mon, 05 Dec 2005 16:05:07 GMT
A new document has been created.

Document ID: 792
Branch: main
Language: default
Name: Vision
Document Type: Cocoon Document
Created: 12/5/05 4:05:00 PM
Creator (owner): Sylvain Wallez
State: draft


Mime type: text/xml
Size: 7169 bytes


<p>This document describes an general vision of the next-generation Cocoon, that
was outlined in the post
"[<a href="">RT] Cocoon
3.0: the necessary mutation</a>" and the discussion that followed.</p>

<p class="warn">This document is a work in progress!</p>

<h1>Why a new version?</h1>

<p>Over the years, Cocoon has become a complex and heavyweight engine. Its power
allow great things to be done once you master it, but the learning curve is so
steep that it frightens newcomers. And considering the current trend of
lightweight frameworks with instant gratification, it's very likely that the
user base will progressively shrink because Cocoon is too complex.</p>

<p>Now Cocoon has a strong potential in the overall web application development
frameworks spectrum: it's one of the very few Java frameworks that bring the
development roundtrip speed of scripted frameworks. This started with automatic
reloading of sitemap, XSLs, flowscript, and even more recently plain Java
classes. So Cocoon is an excellent challenger for the position of "best scripted
framework for Java".</p>

<p>However, Cocoon's positioning suffers a lot of its history. Even if
flowscript is 3 years old, a lot of people still considering as a publication
engine. A new name can allow to clearly show that Cocoon is no more what it used
to be in the 1.x and 2.0.x series. The name <em><strong>Racoon</strong></em>
keeps a sounding close to Cocoon, and shows that we did a lot of cleanup. It
also allows a nice logo and typography (example
<a href="">here</a>)</p>

<h1>Layered architecture</h1>

<p>Racoon should be a layered product, ensuring both strong isolation between
layers, and the ability to reuse some layers and/or components in other
environments. This is a way to strengthen the contracts, but also a way to
ensure that it's not a take-it-all-or-leave product. We have a long history of
pipelined XML processing, and have the ability to provide to the Java world a
clean and easy to use pipeline engine. Cocoon has a strong ability to integrate
third-party products. Racoon should add to this a strong ability to be
integrated in other products.</p>

<p>The layers will be developed in separate artifacts and be distributed
independently, although following the same release schedule. Something similar
to what Spring does, by providing separate jars for beans, AOP, ORM, etc.</p>

<p>At this stage, the following layers are identified:</p>

<li>the pipeline API</li>
<li>the controller</li>

<p>Other elements are to be taken into account such as Forms or Portal, but at
this time we don't know if they should be intermediate layers between pipeline
and controller, or separate modules.</p>

<p>Racoon will be developed as a set of POJOs. The target container is Spring,
but dependencies to the container should be avoided at all costs to ensure
people can reuse our components in other environments.</p>

<h2>The pipeline API</h2>

<p>The lowest layer is the pipeline API. Just as we switched from DOM to SAX
between 1.x and 2.x, Racoon will also introduce a major change, by using pull
processing (StAX) rathern than push processing as defined by the SAX model.</p>

<p>Using pull processing allows to introduce content-aware routing, i.e.
pipelines that are built not only according to the request environment, but also
according to the XML content flowing through the pipeline. This feature, that
wasn't really needed when Cocoon 2.0 was designed, is a must have today with web
services and inter-application integration.</p>

<p>Content-aware routing is something that is most useful in the controller
(javaflow or flowscript), because the pipeline stream is no more used only to
build the view, but also to drive the application processing. It will therefore
be possible to build pipelines in the controller.</p>

<h2>The sitemap</h2>

<p>Do we need the sitemap as it is defined today? With a clearly defined
pipeline API, its role is less important. It may still be available though, as a
thin interpreter on top of the pipeline engine to provide a declarative way to
build views, and as a migration path for users of the current Cocoon.</p>


<p>Our user base comes from different backgrounds: some are heavyweight J2EE
developers, others are less technical and have more a webdesign background.
Racoon should not forget this diversity. That's why the controller will be
available in two versions: Java and JavaScript. This may seem like duplication,
but great care will be taken about providing the <em>same</em> API in both

<p>The controller must consider the new development paradigms brought by Ajax
applications: in many cases, a call to the server doesn't result in the
production of a full page, but sends back one or more partial page updates, or
even raw data. Compared to today's architecture, that means giving access to the
output stream to the controller so that it can send a response without
necessarily going through the pipeline engine.</p>

<h1>Development rules</h1>

<h2>Defining contracts</h2>

<p>A problem that Cocoon suffered is the lack of clear definition of contracts,
and thus the difficulty of knowing what should be part of the backwards
compatibility. Racoon should consider this problem right from the start and
enforce rules that ensure that contracts are clearly defined and documented, and
change only when absolutely necessary. Contracts should be kept as minimal and
simple as possible, while still being expressive enough (e.g. a <tt>Object
process(Map params)</tt> method is minimal and simple, but totally unclear).</p>

<p>A clear distinction should be made between the public and internal classes. A
package naming rule and a prominent warning on internal classes will ensure
people are aware than using them is at their own risk. Public classes must
either be made final or specially designed with subclassing in mind. A tool like
<a href="">clirr</a> can help identifying contract
changes and compatibility issues.</p>


<p>Cocoon also suffered the lack of tests, that lead to some regression problems
in some versions, and did not help in clearly defining the contracts. So all
public classes (and ideally all private classes too) should have unit tests.
Tests verify that contracts are implemented the way they should be, and can also
complement the documentation for low-level behaviours that may not be captured
by the documentation.</p>


<p>We have a shiny CMS, so writing docs should be really part of the development
cycle. Now not all developers are good technical writers, so the minumum should
be that documents be created and their outline written, for others to pick up
and add content.</p>

<h2>Build tools</h2>

<p>In order to manage the large number of 3rd party libraries that can be
integrated, Maven 2 will be used. The project monitoring tools provided by Maven
also provide an invaluable insight on the status of the code.</p>


The document belongs to the following collections: test, Cocoon 3.0

View raw message