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:
http://issues.cocoondev.org//browse/FOR-417
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:
<snip>
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 http://www.burrokeet.org/repositoryData/ 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 example:
<include repository="URL_of_repository"
package="name_of_package"
xpath="path_of_segment"/>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 FORREST_HOME/plugins/IMSManifest/resources/stylesheets/imsmanifest2site.xml
(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 direction.
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.
Ross
-- 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
