forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Dynamic sitemaps
Date Sun, 02 Mar 2003 20:06:48 GMT

First let me say that I've read Stefano's mail and Jeff's reply. I will 
use this mail because it's more complete WRT the actual meat of the 

Another thing: I have already done such a discussion on the cocoon-dev 
ML with a guy that wanted such a system for making multiple developers 
work on the same sitemap without treading on each other. I kept my 
position saying that it was not good for sitemap integrity, because it 
makes the devs loose control of the URI. Nobody brought in a really 
compelling case... but things have changed. Forrest uses Cocoon in a way 
that the original design did not envision. We are writing Cocoon stuff 
for the developer, not for the site directly. So additional requirements 
come into mind, like resource-exists, CAPs, etc. Let's see:

Jeff Turner wrote, On 28/02/2003 13.27:
> 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.

Yeah. Seems like blocks to me.

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

And make me wonder...

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

Yeap, ACK.

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

Hacky or not, they are conceptually needed. Your solution still checks 
for a resource-exists, but it does it "statically". Your proposal is 
tightly binded with the resource-exists thing.

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

Resource-exists "does it" but inside a sitemap. The concept is equivalent.

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


> Thoughts?

Well, as usual I do the "divide et impera" refrain. ;-P

1 - break cocoon sitemap in snippets of functionality
     - This is what blocks will be for.
     - we can use entity includes now, and this could also
       make stefano, who is active now, work faster on blocks ;-P

2 - make it easy for users to add stuff to the pipeline
    - this would make it possible for users to add stuff to
      the sitemap without exposing it. AOP sitemap.
      the point is that Cocoon sitemap should remain
      strictly hierarchical for consistency reasons.
      So with 1 solved, the main one will be easier to
      read and can be completely exposed without fears of
      it being too messy.

3 - make a better resource-exists.
     - the resource-exists paradigm is part of the easy way
       forrest makes it possible to do many things for users.
       It's the *same* conceptual thing as CAPs.
       what we need is to make it more clever WRT caching and
       source indipendent.

4 - make the CAP selector accept an external document for defining
     the DTDs, and an action that gets the relevant stylesheets
     definitions for the conversion from *DTD 2 DocumentDTD11.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message