forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Support for XInclude in tabs.xml and site.xml
Date Sat, 15 Jan 2005 16:05:15 GMT
Sjur Moshagen wrote:
> På 14. jan. 2005 kl. 15.57 skrev Ross Gardler:
>> Sjur Moshagen wrote:
>>> Thanks for the help, it worked.
>>> A new issue is created in the issue tracker, together with a patch. 
>>> Please see:
>>> What's still left: to document the new xinclude function in site.xml 
>>> and tabs.xml, both that it is there, and a simple example on how to 
>>> use it.
>> Yeah I saw that, thanks very much for the patch.
>> I was about to commit it the other day but something struck me and I 
>> don't currently have the time to check it out. Perhaps you could 
>> explain how it works.
>> My problem is understanding how this is helpful because all the XDocs 
>> would have to be in the same directory structure. And since we can 
>> only have one site.xml and one tabs.xml file in each project I'm not 
>> sure how you are making multiple sites. Perhaps a brief example would 
>> make the penny drop for me.
> Here's our background in more detail:


OK, I get it now. Thanks for the clarification.

> Do you see where we are heading? Does it make sense, or could there be 
> better ways of doing it?

There are two other ways that we are aware of, but neither is fully 
implemented as yet.

The most complete solution is implemented in the IMSManifest block. It 
has been agreed that it should be extracted to the core and made to work 
in site.xml. It is in that block simply because the project needing it 
was implemented using IMS Manifests.

Our solution is to import content from a repository. At the moment out 
repository is just a flat file structure accessible via http, but it 
could, of course, be any suitable repository. The root of our repository 
is If you were to visit there 
you would see that it is just a load of Forrest sites (each uses 
IMSManifest rather than site.xml but that is not significant).

Within some of these sites there are special URI's that tell Forrest 
that they should look elsewhere for the actual source files. We use a 
URI because IMS Manifest does not provide a mechanism for inclusion, 
however when porting to site.xml we could introduce a new element, for 

<include repository="URL_of_repository"

This would extract the indicated segment (xpath) from the named package 
(package) located in the indicated repository. Forrest is aware that the 
contents are not from the local document tree and pulls them from 
repository as needed.

At present it is only possible to include the whole of another site, I 
have not implemented the xpath part, but this should be a small matter 
of modifying the XSL.

I'd like to point at the viewSVN urls for the relevant content, but it 
is down right now. To see how it is done take a look in 
(search for "repository")

The big advantage of this is that Forrest automatically gets the 
freshest content from the repository each time the site is built. Of 
course, this is also a disadvantage as the site can't be built if we 
don't have access to the repository (i.e. you need to be online). 
Perhaps the answer is to have forrest checkout the remote content from 
CVS/SVN as you do, it can manage the updates etc. locally.

I'd be happy to work with you on extracting this functionality to core 
and enhancing it accordingly. It seems you have a similar use case to mine.


The second techniques for this is the linkmap. This is Nicola Ken's 
baby. If I understand correctly one of the benefits of this is that the 
location of files is not fixed, the linkmap points forrest in the right 

I'll have to let someone else fill us in on exactly how this works and 
how much overlap there is with the above as I was elsewhere when that 
particular discussion was had.


No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 12/01/2005

View raw message