Return-Path: 
 <forrest-dev-return-5545-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 96309 invoked by uid 500); 29 Apr 2003 12:38:12 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 96278 invoked from network); 29 Apr 2003 12:38:11 -0000
Received: from host190-154.pool80204.interbusiness.it (HELO PC103)
 (80.204.154.190)
  by daedalus.apache.org with SMTP; 29 Apr 2003 12:38:11 -0000
Message-ID: <3EAE71F5.6050806@apache.org>
Date: Tue, 29 Apr 2003 14:37:09 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
CC: cocoon-dev@xml.apache.org
Subject: Re: [RT] Link Rewriting
References: <0405DD53-7984-11D7-92BA-0003935AD2EE@media.demon.co.uk>
 <20030429065020.GA2092@expresso.localdomain> <3EAE4F52.3060804@apache.org>
 <20030429121907.GE2290@expresso.localdomain>
In-Reply-To: <20030429121907.GE2290@expresso.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-GCMulti: 1
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


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="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/)

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"
                   src="http://wiki.cocoondev.org/pages/{1}.txt"/>

to

    <map:generate  type="txt2xml"
                   src="http://mywiki.org/pages/{1}.txt"/>

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

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

Done :-)

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