[RT] Typemaps (Re: [RT] Dynamic sitemaps)

[Jeff Turner <je...@apache.org>]

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
SourceTypeAction:

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

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

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

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

</typemap>

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

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

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

    </map:select>
  </map:act>

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


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

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

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


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.


--Jeff

> 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                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at            http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org                stevenn at apache.org
>