cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Updated: Vision
Date Tue, 06 Dec 2005 10:46:43 GMT
A document has been updated:

http://cocoon.zones.apache.org/daisy/test/792.html

Document ID: 792
Branch: main
Language: default
Name: Vision (unchanged)
Document Type: Cocoon Document (unchanged)
Updated on: 12/6/05 10:46:22 AM
Updated by: Sylvain Wallez

A new version has been created, state: publish

Parts
=====
Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 12066 bytes (previous version: 7169 bytes)
Content diff:
(2 equal lines skipped)
    
    <h1>Introduction</h1>
    
--- <p>This document describes an general vision of the next-generation Cocoon, that
--- was outlined in the post
+++ <p>This document describes an general vision of what could be the
+++ next-generation Cocoon, that was outlined in the post
    "[<a href="http://thread.gmane.org/gmane.text.xml.cocoon.devel/58722">RT] Cocoon
    3.0: the necessary mutation</a>" and the discussion that followed.</p>
    
(2 equal lines skipped)
    <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
+++ allows 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>
(6 equal lines skipped)
    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="http://www.raccoon.balkansnet.org/raccoon-mtl.gif">here</a>)</p>
+++ flowscript is 3 years old, a lot of people still consider Cocoon 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, just like the next generation of
+++ Struts is named
+++ <a href="http://struts.apache.org/struts-shale/index.html">Shale</a>. Now
this
+++ issue will only have to be discussed once something concrete comes out of what
+++ is <strong>an experiment</strong>. Experiments have code names to avoid
+++ confusing people until they either become mainstream or are trashed. Let's use
+++ the word "Raccoon" for this experiment: it rhymes with "cocoon", and raccoons
+++ are well-known for cleaning their food before eating it. And a cleaner Cocoon is
+++ one of the primary goals of this experiment.</p>
    
    <h1>Layered architecture</h1>
    
--- <p>Racoon should be a layered product, ensuring both strong isolation between
+++ <p>Raccoon 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>
+++ clean and easy to use pipeline engine.</p>
    
+++ <p>Cocoon has a strong ability to integrate third-party products, Raccoon should
+++ add to this a <strong>strong ability to be integrated in other
+++ products</strong>. This a way to get out of our ivory tower, and attract new
+++ users even if they don't use only some of the layers and not the full stack.</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>
    
    <ul>
--- <li>the pipeline API</li>
+++ <li>the source resolver</li>
+++ <li>the pipeline API and a limited number of general-purpose generators,
+++ transformers and serializers</li>
    <li>the controller</li>
+++ <li>a modularization mechanism: sitemap mounts and blocks (or their equivalents)
+++ </li>
+++ <li>a servlet integration (the above layers can be used in other environments)
+++ </li>
    </ul>
    
--- <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>Other modules such as Forms, Portals or Ajax are to be taken into account,
+++ but at this time they are more considered as separate modules that site beneath
+++ the above layers.</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>
+++ <p>Raccoon will be developed as a set of POJOs. It's time to finally cut the
+++ link with Avalon. 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>Source resolver</h2>
+++ 
+++ <p>One of the unique and powerful features of Cocoon is the source resolver,
+++ with its extensible support for custom URL schemes, providing transparent
+++ file-like access to virtually any byte stream data source. The source resolver
+++ is a fundamental part of Cocoon, and should be promoted so that it can be can
+++ reused in other environments. Cooperation/integration with
+++ <a href="http://jakarta.apache.org/commons/vfs/">VFS</a> should studied.</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>
+++ between 1.x and 2.x, Raccoon will also introduce a major change, by using pull
+++ processing (StAX) rather 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>This change is motivated by technical reasons: 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>
+++ be possible to build pipelines in the controller. Yes, dynamic pipelines.</p>
    
--- <h2>The sitemap</h2>
+++ <h3>The sitemap</h3>
    
    <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>
+++ pipeline API, its role is less important. It will 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.</p>
    
--- <h2>Controller</h2>
+++ <h3>General purpose generators, transformers and serializers</h3>
    
+++ <p>A pipeline API is useless without components. With the base pipeline
+++ implementation will come a reduced set of general-purpose generators,
+++ transformers and serializers: this is mainly XML parser, XSLT and XInclude
+++ transformers, XML &amp; HTML serializers. Other components will be shipped in
+++ separate modules.</p>
+++ 
+++ <h2>The controller</h2>
+++ 
    <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
(8 equal lines skipped)
    output stream to the controller so that it can send a response without
    necessarily going through the pipeline engine.</p>
    
+++ <h2>Modularization mechanism</h2>
+++ 
+++ <p>The modularization mechanism is about managing "base contexts" and deployment
+++ units.</p>
+++ 
+++ <p>The base contexts are used to write location-independent code:</p>
+++ 
+++ <ul>
+++ <li>the base location of relative URIs used by the source resolver</li>
+++ <li>a request URI prefix that is used to isolate modules from their actual
+++ "mount point" in the HTTP URL space.</li>
+++ </ul>
+++ 
+++ <p>The first one is about the lowest layer in this architecture, and the second
+++ one is about the upper level (see below). Their management should be clearly
+++ separated, even if sitemap mounts change both at once.</p>
+++ 
+++ <p>Giving more power to the controller with dynamic pipelines will also bring
+++ modularization at its level, and changing the base contexts should be possible
+++ in the controller, when a reusable sub-controller has to be called.</p>
+++ 
+++ <p>Deployment units are an ongoing work with the real blocks, and their direct
+++ reuse should be considered.</p>
+++ 
+++ <h2>Servlet integration</h2>
+++ 
+++ <p>Servlet integration only comes at the top of the layer stack. Today's Cocoon
+++ is intimately tied to the servlet request/response paradigm, even if it has been
+++ abstracted and several implementations are available. The main place where this
+++ is visible is the sitemap, where pipeline building is mostly driven by request
+++ URIs, even internal pipelines.</p>
+++ 
+++ <p>The pipeline API allows pipelines to be built in total independence of this
+++ request/response model, which only starts to be required at the controller level
+++ (and even probably not always). The environment abstraction to easily adapt to
+++ request/response implementations other than the servlet will be kept, but the
+++ low-level layers will not depend on it (source resolver, pipeline engine and
+++ base components).</p>
+++ 
+++ <h1>Making things simpler</h1>
+++ 
+++ <p>Cocoon is powerful, but complicated. There are many different languages used,
+++ many different ways of doing the same thing, and many inconsistencies in the way
+++ a given entity is used of accessed in the different parts of an application.</p>
+++ 
+++ <p>The main areas where some simplifications can be made are expression
+++ languages and the object model, that represents the Cocoon environment.</p>
+++ 
+++ <h2>Expression languages</h2>
+++ 
+++ <p>There are dozens of expression languages in Cocoon today: JavaScript, Java,
+++ XReporter, JEXL, XPath, and all the "micro-languages" defined by input modules
+++ (often XPath, but not always).</p>
+++ 
+++ <p>The set of expression languages should be limited to its useful minimum,
+++ which is JavaScript, Java and XPath. And nothing else.</p>
+++ 
+++ <h2>Object model</h2>
+++ 
+++ <p>The object model represents the execution environment: request, response,
+++ context, system properties, configuration, etc. There are currently many
+++ different representations of this object model: a Map in Java, the "cocoon"
+++ object in flowscript, and a large range of input modules.</p>
+++ 
+++ <p>The object model should be clearly defined once, and available identically in
+++ the various layers.</p>
+++ 
+++ <p>Now every layer adds to the global object model: the flow has continuations,
+++ templates have consumers, etc. Each layer can define an additional object model,
+++ <strong>separate from the common one</strong>.</p>
+++ 
    <h1>Development rules</h1>
    
    <h2>Defining contracts</h2>
(15 equal lines skipped)
    
    <h2>Tests</h2>
    
--- <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>Cocoon also suffered from 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>
    
    <h2>Documentation</h2>
    
(13 equal lines skipped)


Fields
======
no changes

Links
=====
no changes

Custom Fields
=============
no changes

Collections
===========
no changes

Mime
View raw message