forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject [RT] Typemaps (Re: [RT] Dynamic sitemaps)
Date Wed, 05 Mar 2003 02:37:53 GMT
On Mon, Mar 03, 2003 at 04:33:29PM +0100, Steven Noels wrote:
> Jeff Turner wrote:
> >I once thought auto-mounted sub-sitemaps could allow us to break up the
> >sitemap, but I'm rather skeptical now.  Once a request is delegated to a
> >subsitemap, it *has* to be handled in that subsitemap.  We can't
> >speculatively throw in a <map:mount>.
> I haven't spend much thinking on this, but couldn't this bad behaviour 
> be caused by the fact we usually map:mount specific 'subdirectories' in 
> our URI space:
> match pattern="foo/**"
>   mount src="mountables/{1}" uri-prefix="mounted/{1}"
> Now if we change the thinking to mounting specific media types instead, 
> would that help? :

It's a good idea.

> match pattern="**.*"
>   mount src="mountablecontenttypes/{2}" uri-prefix=" "
>                                                     ^
> don't know what to put in here ---------------------|
> so that requests for URI = foo/bar/resourcename.mediatype are routed to 
> the sitemap responsible for producing the relevant response for that 
> media type.
> Of course, this brings the discussion back (gee!) of Marc's infamous 
> double extensions, which I strongly despise.

So we can use the same alternative to double extensions, the

<map:match pattern="**">
  <map:act type="sourcetype" src="{0}">
    <map:mount uri-prefix="" src="{sourcetype}.xmap" check-reload="yes" />

And allow the SourceTypeAction to be configured with an external XML
file, perhaps one that also assigns 'types' based on file location:

  <sourcetype name="faq">
    <document-declaration public-id="-//APACHE//DTD FAQ V1.1//EN" />

  <sourcetype name="community-files">
    <location pattern="community/*"/>


So all community/* files would be handled by community-files.xmap

With this, the sitemap can define pipelines for _types_ of files,
regardless of where they are located.  Instead of:

<map:match pattern="body-faq.xml">
<map:match pattern="body-**/faq.xml">
<map:match pattern="body-community/**">

we'd have:

<map:match pattern="**">
  <map:act type="sourcetype" src="{0}">
    <map:select type="parameter">
      <map:parameter name="parameter-selector-test" value="{sourcetype}" />

      <map:when test="faq">
        <map:generate src="content/xdocs/{../0}"/>
        <map:transform src="library/xslt/howto2document.xsl" label="content" />

      <!-- Handle other built-in content types here -->

        <!-- Handle user-defined or optional content types -->
        <map:mount uri-prefix="" src="{sourcetype}.xmap"/>


  <!-- Apply skin to built-in content types -->
  <map:call resource="skinit">
    <map:parameter name="type" value="site2xhtml" />
    <map:parameter name="path" value="{0}" />

That switch is pretty horrible.  We could get rid of it with a

<map:match type="sourcetype" pattern="faq">
  <map:match pattern="**">
    <map:generate src="content/xdocs/{0}"/>

<map:match type="sourcetype" pattern="*">
  <map:mount uri-prefix="" src="{0}.xmap"/>

How does that sound?  With this 'typemap' file, we're introducing a level
of indirection between matchers and pipelines.  Instead of matcher ->
pipeline, we have matcher -> type (user-controlled), and then in the
sitemap, type -> pipeline.


> Also, I don't know whether 
> this will offer more robustness to the mount concept, nor any enhanced 
> modularity. It was just something that came across my mind when reading 
> your mails.
> I have the tendency to agree with your problem statement, but clearly it 
> is one of these border scenarios again, just like reverting the sitemap 
> and the link rewriting thing.
> Hm.
> </Steven>
> -- 
> Steven Noels                  
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at  
> stevenn at                stevenn at

View raw message