After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content.
--tim On 6/4/05, Tim Williams <[EMAIL PROTECTED]> wrote: > Thanks Ross this is great stuff. It seems that locationmap'ed content > is a secondary priority in terms of retrieving content. For a real > world scenario it likely won't matter but for folks testing this out > like me, if there's matching content in the xdocs it seems that it is > retrieved first, then if it doesn't exist, the locationmap matches are > used. > > --tim > > On 6/4/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > > Well Zeph, my son, had a nightmare so I'm wide awake in the middle of > > the night (again), as a result I spent some time on the Locationmap branch. > > > > The good news is that it now works for generating files from a > > repository. I've created a demo within fresh-site (in the locationmap > > branch). The demo shows how to do link rewriting and how to retrieve > > content from a remote repository without having to encode the location > > of the repository or the path to the file within it in the Forrest site URL. > > > > This is pretty powerful stuff. It means we can create single sites from > > multiple repositories, whether they be local, remote or a combination of > > the two. > > > > Next stage is for me to make the Daisy plugin work with the locationmap. > > > > I can't remember who wrote the locationmap code it was so long ago. I > > wish I had had the itch to play with it a long time ago. In my opinion > > this is going to be another key feature of Forrest. > > > > The future of Forrest looks bright: > > > > - Plugins > > - Views > > - Locationmaps > > > > this is killer stuff! > > > > Ross > > >
