Re: cvs commit: xml-cocoon/src/org/apache/cocoon/xml/util DOMBuilder.java DOMFactory.java DOMStreamer.java DocumentHandlerAdapter.java DocumentHandlerWrapper.java NamespacesTable.java XPathAPI.java package.html

[Giacomo Pati <Gi...@pwr.ch>]

Hi all

This commit has changed the hole Cocoon 2 sitemap engine. Of course it
is totaly untested and still has a lot of bugs. So the hunting can
begin. If you do a 'build clean package webapp' the resulting cocoon.war
should be able to be deploy by Tomcat and you can see the welcome page
if you point your browser to /cocoon/welcome.

A lot of classes are being commited of which I didn't know why. I've not
touched Ricardos XSP classes at all but they were commited too????

The hole Sitemap engine consists mainly of three classes in the
org/apache/cocoon/sitemap tree:

Sitemap: This is an Interface which will be implemented by the generated
sitemap. These generated Sitemap classes contains all the logic
expressed in the sitemap.xmap file. These classes are generated by a
stylesheet in
org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl.
It totally lacks of sitemap validation. I'll do this when Ricardo
commits its SLL. The concept of Views are not yet implemented. I'll do
it soon. Also not implemented is the concept of the <map:param> because
it changed the API of the components to make them have access to the
Dictionary the <map:param> will fill. I've enhanced the <map:mount> with
a uri-prefix and a check-reload attribute. uri-prefix is used to tell
the Environment what prefix to strip off the URI in process because the
sitemap cannot reliably determine that of itself. I have to say that the
sitemap has no notion of the environment is runs in beyond the
Environment Interface (and it does't have to for its job). This make it
possible to use Cocoon in every environment you would like as long as
you can create a Environment class and the sitemap components can make
use of its extended functionality. Yes, the sitemap components must know
what extra functionality was build into the Environment object they get
passed along from the Sitemap. The sitemap components are the pieces
that deal with a specific environment.

SitemapHandler: This class physicaly controls all aspects of a generated
Sitemap. It takes care of (re)generation, (re)compilation,
(re)instantiation and initialisation of a single Sitemap. The first
request to a sitemap will trigger a synchronious generation of a
sitemap. If a sitemap changes (and check-reload was set to true) it will
start a thread which generates a new instance of the sitemap. During
this regeneration the requests will be satisfied by the old sitemap
instance. The thread will update this reference as soon as its finished
and the old sitemap object can be garbage collected.

SitemapManager: This class is responsible to manage all sitemaps used in
one node of the sitemap hierarchy. Every Sitemap will have a
SitemapManager which holds all its mounted sub sitemaps. A Sitemap calls
sub sitemaps by use of its SitemapManager. The Cocoon class for example
uses a SitemapManager to pass request to for the root sitemap. The
SitemapManager instanciates a SitemapHandler for each sitemap is has to
manage and passes requests to that SitemapHandler.

Many of the classes in the org/apache/cocoon/sitemap tree are now
obsolete and can be removed.

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch