On Sun, Mar 02, 2003 at 09:06:48PM +0100, Nicola Ken Barozzi wrote:
...
> >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.

*Something* has to examine the files and construct a sitemap, but it
wouldn't be a resource-exists action.  Probably some sort of Libre-like
generator to generate a map of the filesystem with type info, which could
then be converted to a sitemap.

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

Good point.

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

If we used:

  <map:resource name="transform-to-document">
     ...
     <map:act type="sourcetype" src="{src}">
       <map:transform src="resources/stylesheets/{sourcetype}2document.xsl"/>
     </map:act>
  </map:resource>

Then users could add new filetype support simply by creating a new
*2document.xsl stylesheet.

--Jeff