cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: [RT] Link Rewriting
Date Tue, 29 Apr 2003 12:19:07 GMT
On Tue, Apr 29, 2003 at 12:09:22PM +0200, Nicola Ken Barozzi wrote:
> 
> Jeff Turner wrote, On 29/04/2003 8.50:
> ...
> >Now let me play devils advocate..
> >
> ...
> >What's
> >the difference between editing a sitemap.xmap, and editing a linkmap.xml
> >file?  Both just map declarators to SystemIds.
> >
> >In CVS Forrest, we've organized the sitemap into functional layers:
> >
> >LAYER 1       |   (each format or subdir handler in its own sub-sitemap)
> >*.xml         |
> >   various    |    docv11     faq    howto    docbook   community/*  ....
> >   xml types  |       \        |       |         |         /
> >-------------------------------------------------------------------------
> >                         DOCUMENT-V11 INTERMEDIATE FORMAT
> >-------------------------------------------------------------------------
> >LAYER 2       |                /       |               \
> > Intermediate |    **body-*.xml     **menu-*.xml      **tab-*.xml
> > HTML formats |               \        |               /
> >-------------------------------------------------------------------------
> >LAYER 3       |                     \|/       \|/
> >  Output      |                   *.html     *.pdf
> >  formats     |
> >-------------------------------------------------------------------------
> >
> ...
> >In effect, this defines a virtual filesystem of XML sources, completely
> >abstracted from the real filesystem. 
> 
> Exactly.
> 
> ...
> >So what I'm suggesting is that if your users are sufficiently
> >sitemap-savvy, and your sitemap is sufficiently modular, one can have all
> >the benefits of your proposed declarator -> XML linkmapping system.  In
> >fact it's much more powerful; how could a linkmap file handle a RSS file,
> >for example?  You'd need to tweak the sitemap to do the rss2document.xsl
> >conversion.
> 
> It's about SoC. One part defines the source mapping, the other how to 
> process it. I think that he is talking about a scenario where the user 
> does not add new types, but can easily configure just the new places 
> where to find the sources.

Yes, which can be achieved nicely with a sitemap.  For instance, we could
map the whole Wiki source into a Cocoon site with one matcher:

<map:match pattern="wiki/*.xml">
  <map:generate  type="txt2xml" src="http://wiki.cocoondev.org/pages/{1}.txt"/>
  <map:transform type="lexer"   src="resources/grammars/wiki.xlex"/>
  <map:transform type="parser"  src="resources/grammars/wiki.xgrm"/>
  <map:transform src="resources/stylesheets/wiki2document.xsl">
  <map:serialize type="xml"/>
</map:match>

(for people not on forrest-dev, there's a demo of Cocoon Wiki integration
at http://cvs.apache.org/~jefft/forrest/samples/wikirenderer-site/)

> I had committed some time back a refactoring of the sitemap that did 
> just that, but you strongly asked to revert it, so... ;-P

<innocent> Me? </innocent> I don't remember it.. was this the
resource-exists-athon patch?  Anyway..
> 
> So, as I think you also would agree, the important thing is that one 
> modularizes the sitemap so that some pieces can remain as-is, and other 
> parts can be plugged in/expanded separately in each layer:
> 
>  0 - source resolving (for us it's fixed on the filesystem)
>  1 - conversion to common source
>  2 - processing
>  3 - presentation (output)
> 
> What I'd like now is to add level 0 for our sitemap if possible.

In Forrest, 0 and 1 are both handled in forrest.xmap, which defines the
VFS on which everything else builds.  Guess we should take this over to
forrest-dev..

--Jeff

> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 

Mime
View raw message