You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Adam Ratcliffe <ad...@mrigitech.com> on 2005/01/16 23:18:55 UTC

Help with redestructuring of sitemaps and URI space

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:

<webapp-root>
    |
    |--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:

<webapp-root>
    |
    |--customer
    |        |
    |        |--<customer-name>
    |                    |
    |                    |--resources
    |                    |
    |                    |--templates
    |                            |
    |                            |--html
    |--flow
    |--forms
    |--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"
value="cocoon://detectDevice?redirectURI={request:requestURI}"/>
   </map:call>
 </map:act>
</map:match>

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:

     <cinclude:includexml>
       <cinclude:src>cocoon://view/searchForm?contentType=html&amp;action=fi
nd&amp;cid=geosmart</cinclude:src>
     </cinclude:includexml>

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}"/>
      </map:match>

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

Any comments much appreciated.

Cheers
Adam




RE: Help with redestructuring of sitemaps and URI space

Posted by Adam Ratcliffe <ad...@mrigitech.com>.
Hi Mark,

Yes, that's a lot tidier. Thanks very much for your help.

Cheers
Adam

-----Original Message-----
From: Mark Lundquist [mailto:ml@wrinkledog.com]
Sent: Monday, 17 January 2005 7:29 p.m.
To: users@cocoon.apache.org
Subject: Re: Help with redestructuring of sitemaps and URI space



On Jan 16, 2005, at 2:18 PM, Adam Ratcliffe wrote:

>
> 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}"/>
>       </map:match>
>  
> 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.

Right.  You don't want to use a form action that looks like that!  Use
something like

	<form action="#{$continuation/id}.continue">

Then, use these two matchers (just in the top-level sitemap):

     <match pattern="*.continue">
       <call continuation="{1}"/>
     </match>
     <match pattern="**/*.continue">
       <call continuation="{2}"/>
     </match>

...or replace both of them with this:

     <match type="regexp" pattern="(.*/)?([^/].*)\.continue">
       <call continuation="{2}"/>
     </match>

...or, do like some people like to do: take the continuation out of the
form action, and pass it as a hidden form parameter instead.  Search
the list archives for examples of how to do that (or maybe it's on the
wiki)

cheers,
-ml-


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




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


Re: Help with redestructuring of sitemaps and URI space

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 16, 2005, at 2:18 PM, Adam Ratcliffe wrote:

>
> 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}"/>
>       </map:match>
>  
> 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.

Right.  You don't want to use a form action that looks like that!  Use 
something like

	<form action="#{$continuation/id}.continue">

Then, use these two matchers (just in the top-level sitemap):

     <match pattern="*.continue">
       <call continuation="{1}"/>
     </match>
     <match pattern="**/*.continue">
       <call continuation="{2}"/>
     </match>

...or replace both of them with this:

     <match type="regexp" pattern="(.*/)?([^/].*)\.continue">
       <call continuation="{2}"/>
     </match>

...or, do like some people like to do: take the continuation out of the 
form action, and pass it as a hidden form parameter instead.  Search 
the list archives for examples of how to do that (or maybe it's on the 
wiki)

cheers,
-ml-


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


RE: Help with redestructuring of sitemaps and URI space

Posted by Adam Ratcliffe <ad...@mrigitech.com>.
A typo, but it might come to that yet ;-)

Cheers
Adam

-----Original Message-----
From: Mark Lundquist [mailto:ml@wrinkledog.com]
Sent: Monday, 17 January 2005 7:49 p.m.
To: users@cocoon.apache.org
Subject: Re: Help with redestructuring of sitemaps and URI space


BTW, I like your Subject: line...

A typo?  Or a Freudian slip? :-)
-ml-


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




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


Re: Help with redestructuring of sitemaps and URI space

Posted by Mark Lundquist <ml...@wrinkledog.com>.
BTW, I like your Subject: line...

A typo?  Or a Freudian slip? :-)
-ml-


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