cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [Cocoon Devel] Re: [C2] UML Class Diagram for SiteMap
Date Tue, 05 Sep 2000 21:28:44 GMT
Steve Allman wrote:
> I take your response as a NO then ;-)
> To produce a decent representation of the problem space via class diagrams,
> it helps if you understand the problem.
> That was the purpose of my question.

Yes, you're right. Sorry for my too short answer.

The sitemap is such a dynamic thing that I can't think of writing a
class diagram (probably because I rearly do). I usualy use interaction
diagrams to make me see how objects work together. Well, I probably
don't know what you are asking for so here is the way the main classes
work together:


The CocoonServlet (instantiated by the servlet engine) creates a Cocoon
objects by passing it the file cocoon.xconf which defines the general
components to the cocoon system (like parser, store, svg encoders, the
XSP engine components, etc.). These general components are managed by
the Cocoon object by means of its ComponentManager implementation. 

Also mentioned in the cocoon.xconf is the sitemap.xmap file. This file
contains the definitions of SitemapModelComponents and
SitemapOutputComponents in general (or Generators, Transformers,
Serializers, Matchers, Readers and Selectors to be more specific). These
classes can implement various interfaces (Component, Composer,
Configurable, and many more) to signal their behaviour to the sitemap
which, according to the IOC (inversion of control or also known as
Hollywood principle which means 'don't call us, we call you'), will
instanciate and configure them. 

The sitemap.xmap file also defines constructs like views (which defines
an other dimensional view of the resource requested), resources
(shorthands for pipeline component composition) and pipelines (which
describes the way to assemble an actual pipeline). 

The sitemap.xmap file itself will be translated into java source code
and compiled by the XSP engine for performance reasons. This process is
controlled by the SitemapHandler (mentioned above) which will take care
of an actual instance of the sitemap.xmap file by checking its
modification date. This code generation and compilation step will
(except for the first time) be done in a separate thread. During this
regeneration process requests are handled by the still existing old
instance of the sitemap.xmap file. Because of this behaviour changes to
the sitemap.xmap file will not be reflected immediately. 

And least there is a SitemapManager which takes care of SitemapHandlers
according to <map:mount> definitions in the sitemap.xmap pipelines. The
Cocoon object has one SitemapManager which has one SitemapHandler which
always has one instance of a sitemap.xmap file. The instance of the
sitemap.xmap file has a SitemapManager which may control several
SitemapHandlers which controls a sub sitemap file (according to the
mount definitions) and also this sub sitemap instance has a
SitemapManager which ... so on.


If I have forgotten something you might find the
xdocs/draft/sitemap-working-draft.xmap reasonable for further
information. Now I hope you can do something with this stuff :)


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703 
CH-8166 Niederweningen           

View raw message