cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Ratcliffe" <>
Subject Help with redestructuring of sitemaps and URI space
Date Sun, 16 Jan 2005 22:18:55 GMT
I'm looking to restructure my application URI space/sitemap hierarchy to
address some of the more awkward
features of the existing design.  As it's possible I'm not the first person
to come up against these issues I'm sharing them
with the list in the hope of getting some comment on refactoring the design.

The application is an online mapping solution that provides services for
finding locations, routing from one location to another,
and map display and navigation.

There is both a public site and customer-specific sites, all sites are
served by the same web application with sub-sitemaps
providing the application entry-points for each customer.  As of today the
application is not internationalized and the content
output format is always HTML, however in the future we will be needing to
support other languages and output formats.

The sitemap hierarchy looks like this:

    |--sitemap.xmap (standard cocoon sitemap), mounts application sitemap
            |--application.xmap (provides internal pipelines for functions
common to all sites; provides pipelines for producing
                    |                     content that's generic to all
sites, for example forms and map display)
                    |--customer.xmap (provides pipelines for producing
content specific to a particular customer)

and the app directory structure:

    |        |
    |        |--<customer-name>
    |                    |
    |                    |--resources
    |                    |
    |                    |--templates
    |                            |
    |                            |--html
    |--xsl etc

In a typical application use-case a user would access the application
through a URI defined in a customer sitemap
(customer.xmap); following successful authentication an internal pipeline
would be invoked in the top-level sitemap (application.xmap).

A pipeline for this use-case looks like this:

<map:match pattern="">
 <map:act type="auth-protect">
   <map:parameter name="handler" value="defaultHandler"/>
   <map:call function="hasDevice">
     <map:parameter name="successURI" value="cocoon://search"/>
     <map:parameter name="failureURI"

The internal pipeline calls a flow function that after performing some
business logic calls sendPage() with the URI of an output
page in the customer sitemap.  This page works like a template as it
includes content from pipelines in the top-level
sitemap using the CInclude transformer.  For instance the map display page
is common to all customers

An excerpt from one of these pages that includes a form for searching for
locations looks like this:


A problem with this approach is that the contextPath, necessary for
resolving relative URLs, needs to be passed from the customer
sitemap back to the top-level sitemap so that the flow functions know the
appropriate sitemap to pass control back to generate the
output page.

Another issue occurs with sendPageAndWait() and showForm() calls where the
pipeline matching the continuation URI in the customer
sitemap needs to redirect to a pipeline in the top-level sitemap where the
flowscript is included:

      <map:match pattern="continue.*">
         <map:redirect-to uri="cocoon://continue.{1}"/>

If the continuation is not matched by the customer sitemap but instead
matched by the top-level sitemap, using a form action like:
'../../continue.#{$continuation/id}' the contextPath will be that of the
top-level sitemap and relative URLs in the output page will no
longer be relative to the customer directory.

The application as it stands works fine but it can be difficult to
understand the relationship of the rules involved in page content

Any comments much appreciated.


View raw message