Sjur Moshagen wrote:
P� 15. jan. 2005 kl. 18.05 skrev Ross Gardler:
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.
This is also what we do.
With one very important difference, for us, Forrest does it at runtime. There is no need for the content developers to import the docs, this is very important for us as most of our content developers are not technically aware, using a word processor is about their limit.
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.
We should probably deal with the two issues separately:
1) flexible inclusion of what is wanted 2) update/checkout of the local copy
1) is very easily handled with XInclude - all xpath handling is already there.
With Forrest as it currently stands, XInclude is only sufficient if the source is available locally. For us the repository could be anywhere.
2) I have no concrete suggestion on this one.
At present we use the document() function of XSLT to bring in the remote document. This means we can provide a pipeline that pulls the data from the relevant repository (here I am referring to CVS/SVN type repositories for you and Learning Object repositories for myself). This pipeline can be responsible for managing a local cache of the data.
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.
I'll have to look into IMSManifest. Presently we (or I, that is:-) would like to go for the XInclude solution, to get our site up and running AFAP. That does not preclude that we also look into other solutions that would also take care of repository checkouts/updates.
Absolutely, you need to get things working for your project (and I will apply your patch since it does not affect other aspects of Forrest).
I just thought that we have an amount of overlap between our two use cases and wanted to explore that. I suppose the real question I should be asking you is "would automatic management of included documents be a benefit in your case?"
One of our concerns would be i18n - we can only live with a solution that integrates well with the i18n work done (and planned) in Forrest.
Well I have not done any work with i18n, but I see no reason why our own approach should br3eak this functionality since everything is converted to a site.xml and tabs.xml file and then handled internally by Forrest in exactly the same way.
This means that improvements to the core i18n funcitonlaity should be avilable to all solutions.
Ross
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
