forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject [RT] Dynamic sitemaps
Date Fri, 28 Feb 2003 12:27:12 GMT
Hi,

I was idly thinking, lots of things are pointing to a future need for a
more dynamic sitemap:

- We need a way to assemble a sitemap, pulling in only the snippets that
  the user needs.  Eg, most people don't need the community/* support, or
  XML from DTDs, or Forrest's JIRA feed.
- We need a way to let users plug in new document types, without hacking
  the original sitemap.
- More and more, resource-exists actions are creeping into the Forrest
  sitemap.

Right now, we're just piling more stuff into the default sitemap.  The
complexity is already quite intimidating, and discourages users from
experimenting with the sitemap.  Without knowing how to exploit the
sitemap's flexibility, Forrest is just a frustrating black box.

So how do we handle this problem?

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

One option is to dynamically create a sitemap.xmap using XSLT, much like
the Forrestbot creates Ant scripts.  Yuck..


                              -o0o-
 

Anyway, what this RT is really about is this suggestion: we use a Cocoon
pipeline to dynamically generate a sitemap, which is then mounted.  We
have a 'primordial' sitemap as follows:

<map:pipeline>
  <map:match pattern="sitemap">
  ...
  </map:match>
</map:pipeline>

<map:pipeline>
  <map:match pattern="**">
    <map:mount uri-prefix="" src="cocoon:/sitemap" check-reload="no" />
  </map:match>
</map:pipeline>

The 'sitemap' matcher then assembles a sitemap unique to the current
project.  We can have configuration files which direct the assembly of
the sitemap, or even inspect the xdocs themselves (if a community/
directory is present, pull in community/* matchers).  This way, we can
get rid of all those hacky resource-exists checks.

I don't know how kindly the sitemap engine would take this kind of abuse.
If it had to regenerate a subsitemap for each request, things would
certainly be too slow.

At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
Sources, but I imagine that could be fixed.

Thoughts?

--Jeff

Mime
View raw message