forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Link Rewriting
Date Tue, 29 Apr 2003 12:37:09 GMT

Jeff Turner wrote, On 29/04/2003 14.19:
> On Tue, Apr 29, 2003 at 12:09:22PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote, On 29/04/2003 8.50:
>>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="{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

Ok, so you give away the sitemap, and the user wants to use it to show 
his wiki. So he goes in the sitemap and changes

    <map:generate  type="txt2xml"


    <map:generate  type="txt2xml"

Then we come out with a new version of the sitemap, and the user has to 
again manually change the new sitemap...

It's the same thing I have discussed with the news section, etc. If you 
want to use sitemaps as reusable blocks, you have to separate the source 
resoilving and the processing blocks. The above does both.

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

Yes, it was that ;-P  I centralized obtaining the source in a single 
place ;-)

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

Yes, as I'm trying to say, I have understood that making a new design 
for this is not needed as proper layering of sitemaps can do it.
So I would propose that we have a sources.xmap and a forrest.xmap.

The sources.xmap would do the mapping that now is done by the

>  Guess we should take this over to
>  forrest-dev..

Done :-)

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

View raw message