cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 11:09:17 GMT
Cocoon is simple conceptually.
Cocoon is a beast implementation-wise.

Why?

It's monolithic.

So?

Let's modularize it :-)

                 -oOo-

To get back to a simple Cocoon, we need to define what Cocoon is.

---------------------
   What is Cocoon?
---------------------

Cocoon is a resource processing engine based on XML and written in Java.

/Eh? wasn't it a web application server?/

It's mainly used as such, but it's more general in use.
We can schematize Cocoon as a black box that recieves inputs from an 
environment, processes these inputs via XML, and returns resources to 
the caller.
These resources can be XML files, HTML files, Excel files, other files, 
XML or SQL databases, Web forms, Web services, and whatever can be 
transformed in XML for processing. Also non-XMLable resources can be 
processed by Cocoon, but the most flexible way passes from XML format.

---------------------
   What is the core?
---------------------

Now, has anyone easily used Cocoon out of a Servlet environment?

We need a _CocoonBean_, that becomes the core entry point.
You give it a sitemap, input, and it processes the output. Simple as that.

The Cocoon core is layered in two, the pipelines and the sitemap 
selection-action stuff.


---------------------------
   What can we do about it?
---------------------------

1) Please take a look at Morphos in jakarta-commons-sandbox.
    It's a project that defines pipelines and stages to transform objects
    into other objects.
    I have already ported the poi HSSF there as a Morpher.

    This can be the pipeline part of the core.

2) Use the pipelines into a Sitemap processing system, with
    the CocoonBean as the entry-point.

3) Move all implementations in indipendent sub-projects.

4) Make the environments all use the CocoonBean.

5) Separate and document the location phase from the generation phase, 
via sources.

Mind me, these are *conceptual* possibilities, on implementations there 
will be much yet to decide; also, all this must be done mostly via 
refactoring, not via rewriting.
I am using the free4apache Refactorit and it works well :-)


"Groups are allowed to create a branch for release cycles, etc. They are 
expected to merge completely back with the main branch as soon as their 
release cycle is complete."

If nobody objects, I will branch on 7 August 2002 and start refactoring.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message