cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernhard Huber <>
Subject Re: sitemap design - model and process
Date Sat, 12 Oct 2002 16:36:33 GMT

>The idea sounds excellent Berni. Would you please
>explain a little more about how you see this
>process working. Is it ...
>UML (model of a particular sitemap instance)
> |
>XMI (interchange of model via XML)
> |
>XSLT (xmi2sitemap.xsl)
> |
>XML (the sitemap.xmap instance)
>The Cocoon sitemap probably *is* the model,
>as you say. However, it can be modelled using
>something else and then represented as a Sitemap.
that's already a solution,
The challenge is to define the UML, UML is very general,
As the current UML tools allows you define any kind of classes.
But we have already Cocoon which defines the runtime behaviour of our 
model, already.

>I probably display ignorance, but who cares if it
>leads to something useful. I went googling a came
>across a reliable starting point:
> Conceptual Modeling and Markup Languages
Thanks for your response, you presented already the solution,
i checked your link, too, thx for the "conceptual modelling" hint,
i tried to be a bit more specific about my ideas,
comments are very welcome

Conceptual Modelling A WebSite

A model for modelling a web site, the model should describe a
web site using UML.
The model should help managing a web site using Cocoon.

The model should generate some, or all
Cocoon configuration files especially the sitemap.xmap files
of the cocoon hosted website.


  uri space - names for accessing resources, documents of a website
  document  - some sort of content accessible from the website
  sitemap   - mapping rules from the "virtual" uri space to some
              physical space, eg. filesystem names, application names, etc.

Identifying design patterns

  Identifying design patterns in the sitemap helps communicating about
  realizing the model of a website using Cocoon.
  As a result we may find that some requirements of a website
    * implemented in the sitemap
    * implemented in some sitemap object, like generator, transformer, etc.
    * scattered around in more than one spot in the sitemap
  As a long term result we may yield a sitemap metric.

Design Pattern Catalogue

  As a starting point I'd like to introduce some design patterns 
identified so far
  in cocoon sitemaps. The examples are taken from the forrest sitemap.

  Introducing these design patterns into the Cocoon's context should help
  to understand and manage Cocoon's sitemap more easily.
  These design patterns are an abstraction of Cocoon's sitemap objects.
  The naming of the design patterns are used from the GoF Design 
Patterns book.

* Resource
The overall abstraction of all classes of the sitemap model.

* XMLDocumentResource, XSLTDocumentResource
Leaf classes of the sitemap model, there is a 1:1 mapping to
physical resources   

  * AbstractComposite
A composition of a resource, AbstractBuilder, AbstractDecorator, 
are inherited from this abstraction.

  * AbstractBuilder, MenuBuilder, AggregateBuilder, DocumentBuilder
A builder of some resource, it abstracts the processing of some resource,
the result of this processing is the product of the builder, the
result of a builder is a resource

  * AbstractDecorator, SkinningDecorator
An augmentation of resource

  * AbstractProxy, AssociationProxy, MatchingProxy, SelectorProxy
Abstraction of some sort of mapping from a source to a resource

A Sitemap Modeller Tool

  Finally I like to give some pratical usage of the above described 
design patterns.

As of today UML Tool are used for modelling systems, and generating some 
language code.
Now in the Cocoon context the 'language code' should be the sitmap xml 

The classes modelled in an UML tool might use directly sitemap elements, 
moreover the
design patterns, described above. Hence as a website manager you don't 
have to
add classes to the UML model, but you might add desing pattern which are an
abstraction of one ore more cocoon elements.

Editing cocoon's sitemap means editing the object diagram of the UML Tool.

Collaboration, and Sequence diagramms should be auto-generatable as the
dynamic behaviour of the sitemap model is already defined by the Cocoon 

Case Study Forrest site

  The following section describes the forrest site, identifying 
  assumptions, and requirements. Moreover I try to identify
  patterns in the sitemap for implementing the assumptions and requirements.
  HTML documents are mapped to files with extension .html.
  PDF documents are mapped to file having extension .pdf.
  Images are mapped to file having extension .gif, .jpg, and .png, residing
  in directory images.

  The skinning of the forrest web site is defined in the skin directory, and
  consists of javascript files, css files, and images files in the 
images directory.

  The filesystem and uri space layout has following tree structure:
  |   /---images
  |   /---howto
  |       +---v10
  |       +---xmlform
  |       +---bugzilla-patch
  |       |   /---my-images
  |       /---cvs-ssh
  |   /---xml-site

  Uri space patterns
    1. Each document has a html, and a pdf form, residing in the same 
       the html document has the extension .html,
       the pdf document variant has the extension .pdf.

    2. Images, skin information reside in forrest web site global 
directory image, and skin.
       As this date is shared by all web pages centeralizing these 
resources helps browsers
       caching these info, and reducing resource consumption, on the 
server, and client side.

  Consequences of the uri space patterns
    The uri space patterns above have consequences defining the cocoon 

    There are matching rules for uri-pattern of the form like '*.pdf' for
    generating pdf documents.
    There are matching rules for uri-pattern of the form like '*.html' for
    generating html documents.

    Centeralized resources for images, javascript, css etc are never 
relative to the
    current document, but always relative to the context-root of the 
site. This allows
    documents to share images, reducing bandwidth, and allowing proxy 
and browser to
    cache resources.

To unsubscribe, e-mail:
For additional commands, email:

View raw message