forrest-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 14:19:44 GMT
(detaching cocoon-dev)

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

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

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


--Jeff

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

Mime
View raw message