cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [C2-RT] Sitemap Concern Mixing
Date Thu, 24 May 2001 17:57:44 GMT
Here is a random thought that I had regarding the sitemap, to help
segregate some concerns.  If we like this approach, it should be
targeted for next version of Cocoon (2.1?), but I want to get it
out there anyway.

When designing a portal, there are several concerns that are somewhat
mixed up in the C2 sitemap.  Below is a list of concern areas covered
by the current sitemap:

* Component Definitions -- these could easily be done in cocoon.xconf,
                           but they are present in sitemap.

* Action Set definitions -- Action Sets are inherent to a resource, or
                            group of resources.  Stefano's FlowMap
                            proposal is a better place for these.

* Resource Definitions -- Represent a complete flow from generator to
                          serializer.

* View Definitions -- Represent different ways of serializing the same
                      information.

* Pipeline Definitions -- when I snag URI 'x' Cocoon processes the resource
                          in method 'y'.

* Aggregation Definitions -- Assembling a larger page from smaller pages

* Dynamic sitemap control -- If browser 'x' requests resource 'y', alter
                             processing in manner 'z'

There are more concerns to be sure--especially if a flowmap concept is
thrown in the mix.  The restructuring I want to propose will separate
concepts that can be cleanly separated, while better realizing the idea
and principals behind the Sitemap.

The sitemap is so integral to the way Cocoon works, my other developers
have spent a long time trying to grok the sitemap--despite the fact that
I set up the processing scheme so we were all using the same stylesheets.

We are developing an application that is very structured, and is mapped
like this:


+----------------------------------------+
|                 HEADER                 |
+----------------------------------------+
|          MAIN NAVIGATION MENU          |
+---------+------------------------------+
|         |                              |
|         |                              |
|         |                              |
| CONTEXT |                              |
|   MENU  |           BODY               |
|         |                              |
|         |                              |
|         |                              |
|         |                              |
+---------+------------------------------+

This is a great candidate for Aggregation and templating.  So I would like
to have an aggregation statement that creates something like this:


<layout>
  <header/>
  <navigation/>
  <page-links/>
  <body/>
</layout>

This is pretty cool except for a few key issues:

The <header/> section pulls the title from the <document> markup I am using,
as well as keywords.

The <page-links/> section derives the links from the content of the <document>
markup.

In fact, the only two sections that will work classically with the current
aggregation system is the <navigation/> and <body/> sections.

I would like to be able to incorporate the results from one sitemap pipeline
in another--kind of like a psuedo inheritance.  In order to do this now, we
have to use some ugly syntax:

<map:match pattern="**.xml">
  <map:generate src="docs/{1}.xml"/>
  <map:transform src="stylesheets/proprietary2document.xsl"/>
  <map:transform src="stylesheets/list2document.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="**.header">
  <map:aggregate element="header">
    <map:part src="{1}.xml"/>
  </map:aggregate>

  <map:transform src="stylesheets/document2header.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="**.page">
  <map:aggregate element="page-links">
    <map:part src="{1}.xml"/>
  </map:aggregate>

  <map:transform src="stylesheets/document2page.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="menu">
  <map:redirect-to resource="menu"/>
</map:match>

<map:match pattern="**.html">
  <map:aggregate element="layout">
    <map:part element="header" src="{1}.header"/>
    <map:part element="navigation" src="menu"/>
    <map:part element="page-links" src="{1}.page"/>
    <map:part element="body" src="{1}.xml"/>
  </map:aggregate>

  <map:transform src="stylesheets/layout2html.xsl"/>
  <map:serialize type="html"/>
</map:match>

<map:match pattern="**.pdf">
  <map:aggregate element="layout">
    <map:part element="header" src="{1}.header"/>
    <map:part element="navigation" src="menu"/>
    <map:part element="page-links" src="{1}.page"/>
    <map:part element="body" src="{1}.xml"/>
  </map:aggregate>

  <map:transform src="stylesheets/layout2fo.xsl"/>
  <map:serialize type="fo2pdf"/>
</map:match>

As you can see this is quite messy.  I don't like the fact that you have to have
several aggregations when one should be possible.  There are two approaches to
minimizing all this extra syntax without violating the specialness of the sitemap:
Altering resource/view semantics, and one special case "generator" called include.
The include parlance would rewrite the above like this:


<map:match pattern="**.xml">
  <map:generate src="docs/{1}.xml"/>
  <map:transform src="stylesheets/proprietary2document.xsl"/>
  <map:transform src="stylesheets/list2document.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="**.header">
  <map:include pipeline="{1}.xml"/>

  <map:transform src="stylesheets/document2header.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="**.page">
  <map:include pipeline="{1}.xml"/>

  <map:transform src="stylesheets/document2page.xsl"/>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="menu">
  <map:redirect-to resource="menu"/>
</map:match>

<map:match pattern="**.layout">
  <map:aggregate element="layout">
    <map:part src="{1}.header"/>
    <map:part element="navigation" src="menu"/>
    <map:part src="{1}.page"/>
    <map:part element="body" src="{1}.xml"/>
  </map:aggregate>
  <map:serialize type="xml"/>
</map:match>

<map:match pattern="**.html">
  <map:include pipeline="{1}.layout"/>
  <map:transform src="stylesheets/layout2html.xsl"/>
  <map:serialize type="html"/>
</map:match>

<map:match pattern="**.pdf">
  <map:include pipeline="{1}.layout"/>
  <map:transform src="stylesheets/layout2fo.xsl"/>
  <map:serialize type="fo2pdf"/>
</map:match>

The include methodology is pretty straight forward, and it's semantics conform
to the concern area of the sitemap.  Basically, it is a one part aggregation,
with no root element.  It is also much more readable.  I would envision two
uses for the <map:include> element:

<map:include pipeline="pipeline/path"/>
<map:include resource="resource-name"/>

I like this approach alot.

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


Mime
View raw message