sitemap design - model and process

[Bernhard Huber <be...@a1.net>]

hi,

I'm thinking about a model for designing a cocoon sitemap.

You might say just edit the sitemap sitemap.xmap with an editor,
and that's it.

But I was downloading forrest, and i'm surely impressed by the
nice skin, and the visual design, but i'm a bit too lazy for walking through
all the sitemap, and build scripts for understanding the design.

Thus I would be very happy for having a model for the forrest site.

Moreover i'm thinking that for a team using cocoon it would be very helpful
for having some sort of model, and some sort of process for creating,
and maintaining the sitemap, and its mounted sitemap.

I was thinking of describing, and designing a sitemap by using UML,
as i think UML is the right language for that.

Note: I'm not interested in an Reverse-Engineering using an UML tool of
the existing java code. That's not what i want. The solution of this effort
should help the web site team for maintaining a website.

I want a model for WebMaster, WebStyleDesigner, and WebApplication 
programmer
for designing, creating, and maintaing a site.

Perhaps i didn't understand Cocoon completly, as cocoon sitemap might be 
the model,
but I think a team might need some more documents, than a plain xml 
document for
mainting a site powered by Cocoon.

Does anybody have similiar ideas?
Any input is welcome.

bye bernhard



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

Re: sitemap design - model and process

[Bernhard Huber <be...@a1.net>]

hi,

>Looks useful.
>Plan to submit to the C2.1 docs?
>
yes, i'd like to submit it to the docs.
but i'd like to wait, it needs some more review.

bye bernhard



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

Re: sitemap design - model and process

[Ivelin Ivanov <iv...@apache.org>]

Looks useful.
Plan to submit to the C2.1 docs?


----- Original Message ----- 
From: "Bernhard Huber" <be...@a1.net>
To: <co...@xml.apache.org>
Sent: Saturday, October 12, 2002 7:13 PM
Subject: Re: sitemap design - model and process


> hi,
> i added the uml model of the design patterns, see
> http://members.a1.net/berni_huber/solutions/conceptual-modelling.html
> for details
> bye bernhard
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


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

Re: sitemap design - model and process

[Bernhard Huber <be...@a1.net>]

hi,
i added the uml model of the design patterns, see
http://members.a1.net/berni_huber/solutions/conceptual-modelling.html
for details
bye bernhard




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

Re: sitemap design - model and process

[Bernhard Huber <be...@a1.net>]

hi,

>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
> http://xml.coverpages.org/conceptualModeling.html
>  
>
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.

Keywords

  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, 
AbstractProxy
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 
programming
language code.
Now in the Cocoon context the 'language code' should be the sitmap xml 
document.

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 
implementation.

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:
  /
  +---skin
  |   /---images
  +---images
  +---community
  |   /---howto
  |       +---v10
  |       +---xmlform
  |       +---bugzilla-patch
  |       |   /---my-images
  |       /---cvs-ssh
  +---xml-site
  |   /---xml-site
  /---howto
      /---xmlform

 
  Uri space patterns
    1. Each document has a html, and a pdf form, residing in the same 
directory,
       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 
sitemap.xmap.

    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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: sitemap design - model and process

[David Crossley <cr...@indexgeo.com.au>]

Bernhard Huber wrote:
> hi,
> 
> I'm thinking about a model for designing a cocoon sitemap.
> 
> You might say just edit the sitemap sitemap.xmap with an editor,
> and that's it.
> 
> But I was downloading forrest, and i'm surely impressed by the
> nice skin, and the visual design, but i'm a bit too lazy for walking through
> all the sitemap, and build scripts for understanding the design.
> 
> Thus I would be very happy for having a model for the forrest site.
> 
> Moreover i'm thinking that for a team using cocoon it would be very helpful
> for having some sort of model, and some sort of process for creating,
> and maintaining the sitemap, and its mounted sitemap.
> 
> I was thinking of describing, and designing a sitemap by using UML,
> as i think UML is the right language for that.
> 
> Note: I'm not interested in an Reverse-Engineering using an UML tool of
> the existing java code. That's not what i want. The solution of this effort
> should help the web site team for maintaining a website.
> 
> I want a model for WebMaster, WebStyleDesigner, and WebApplication 
> programmer
> for designing, creating, and maintaing a site.
> 
> Perhaps i didn't understand Cocoon completly, as cocoon sitemap might be 
> the model,
> but I think a team might need some more documents, than a plain xml 
> document for
> mainting a site powered by Cocoon.
> 
> Does anybody have similiar ideas?
> Any input is welcome.
> 
> bye bernhard

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.

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
 http://xml.coverpages.org/conceptualModeling.html

--David


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