forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Link Rewriting
Date Tue, 29 Apr 2003 17:01:14 GMT

Jeff Turner wrote, On 29/04/2003 16.19:
> (detaching cocoon-dev)

Ouch! ;-)

> On Tue, Apr 29, 2003 at 02:37:09PM +0200, Nicola Ken Barozzi wrote:
...
>>Then we come out with a new version of the sitemap, and the user has to 
>>again manually change the new sitemap...
> 
> Oh yes..
> 
>>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.
> 
> Is "the above" the suggestion to look up sources in an XML file?

I mean the conceptual thing, not implementation.

>>>>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 ;-)
> 
> I thought it was about getting rid of xdocs/.

Not really, but it doesn't matter, as now we are doing it, and much 
better :-)

>>>>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.
> 
> 
> I was thinking we could do that by defining the project structure in XML,
> like Centipede's layout.xml used to:
> 
> <dir path="/">
>   <dir id="content" path="src/documentation/content/">
>     <dir id="xdocs" path="xdocs/"/>
>   </dir>
>   <dir id="resources" path="resources/">
>     <dir id="images" path="images/"/>
>   </dir>
> </dir>
> 
> And then using an InputModule to make this available to the sitemap:
> 
> <map:match pattern="images/**.*">
>   <map:read src="{layout:resources.images}/{1}.{2}" mime-type="{2}"/>
> </map:match>
> 
> The layout XML would also be available to XSLTs via something like
> document('cocoon:/layout.xml').
> 
> Isn't this XML more or less what a resourcemap is?

Well, you have put in nice xml what I still had as only a concept...
Hey, I mad you do work for me! <the-force>Yayyyyy!</the-force> ;-)

Ok, I'm joking... actually that was the first idea:

On 14/10/2002 17.56 Nicola Ken Barozzi wrote:
  <resourcemap>
     <mount space="/javadocs" resource="file://../../tools/javadocs">
     <mount space="/" resource="file://.">
   </resourcemap>

  <resourcemap>
     <mount space="/javadocs"
            resource="file://../../tools/javadocs">

     <mount space="/code/sourcedocs"
            resource="myprotocol:/path/to/docs">

     <mount space="/"
            resource="file://.">
   </resourcemap>

But as you know I'm not able to look near even if I have to wear 
glasses, so I came up with (conceptual)

  <resourcemap>
     <match resource="/javadocs/*"
            src="file://tools/javadocs/{1}.html">
     <match resource="/"
            src="file://.">
   </resourcemap>

Opps, it's looking more and more like a sitemap snippet ;-)

I though I sent a mail on this but somehow it didn't go through o I 
can't find it.

Anyway, we can simply expose to the users a sitemap that exposes these 
resources, that can be gotten from the pipelines as cocoon://

Example resources.xmap:

<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
   <map:components>...</map:components>

   <map:pipelines>
     <map:pipeline>
       <!-- main resoure match -->
       <map:match pattern="forrest-resource/**.dtdx.xml">

<!-- ***** users can change from here... ***** -->

         <!-- Include external newsfeeds -->
         <map:match pattern="content/xdocs/sitenews.xml">
           <map:generate type="html" src="http://mysire/rss">
           <map:serialize type="xml"/>
         </map:match>

         <!-- #project.content-dir -->
         <map:match pattern="content/**">
           <map:generate src="content/{1}">
           <map:serialize type="xml"/>
         </map:match>

         <!-- #project.xdocs-dir -->
         <map:match pattern="content/xdocs/**.xml">
           <map:generate src="content/xdocs/{1}.xml">
           <map:serialize type="xml"/>
         </map:match>

         <!-- etc -->

<!-- ************** ... till here ************** -->

       </map:match>
     </map:pipeline>
   </map:pipelines>
</map:sitemap>


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


Mime
View raw message