Ferdinand Soethe wrote:
[moved to the Forrest dev list since this has now turned to issues regarding the development of Forrest -
Background for Forrest devs: this mail is part of a thread between myself and Ferdinand discussing our ApacheeCon presentation and features we may implement to illustrate some of our points]
- I extend the OOplugin to convert that glossary markup into a link (<a href="">...</a>) where the URL follows the rules you tell me are required for your glossary plugin.
- you make the glossary-plugin work in Forrest and Burrokeet.
we are done :-)
+1
Time allowing I will see if I can make the Daisy editor and/or the htmlArea editor work like this too.
Say I have a dir structure like
xdocs/
files ...
about/
work/
demo/
mywiki/
index.wiki
install.wiki
wikidirs/
howtoUseDirs.wiki
sortingDirs.wiki
wikisyntax/
howtoWriteAWikiFile.wiki
and I only wanted to apply the automatic generation of
site entries to the mywiki/ subdir,
- could we have a plugin that will parse the dir structure from mywiki/ downwards? Yes, I know we can with cocoon directory transformer
- can we generate site structure from the dir structure and the filenames? Yes
- How can we make the plugin insert the resulting site structure into the manually edited structure in site.xml.
Could I for example have a special uri so that a site element like
<mywiki label="My Wiki" href="automatedDirectory/demo/mywiki"/>
= would automatically generate the site struture? Yes as this is similar to S5 using a prefix to the url to trigger a pipeline!
[update for devs: this would be an internal plugin we would build to illustrate the extension of core internal functionality]
No, this is not the same as the s5 plugin. In the s5 plugin it is the request that triggers the processing by the s5 plugin. In this case there is no request generated when the site.xml file is processed.
[OT: The s5 plugin will be changing the way it does this because it is bad design to have the URL indicate the format of the file being served. Instead of 's5slides/presentation.html' it will be 'presentation.s5' or presentation.s5.html]
I see two ways of doing what you want.
We could change the XSL that builds the site.xml file so that it looks for something like:
<myWiki label="MyWiki" type="auto"/>
This would then make a request for something like:
demo/mywiki/site.auto.xml
which would then provide the site.xml snippet.
Alternatively (and more simply), we could do:
<xi:include src="demo/mywiki/site.auto.xml"/>
= would insert the inserted structure in place of the
<mywiki>-element into the final sitemap?
That should be possible but may be I'm too optmistic here.
I think the above solutions will do the job just fine.
My reasons behind this proposal:
You and I talked about the usefulness of such a plugin in general. Our main problem was that parsing the complete dir structure of a big site might take to long. And - may I add - perhaps people would want to use anvanced techniques for some of the site but allow for easy maintenance for others.
By being able to have it process only part of the tree, we solve both problems.
Let me know if this is too much work, otherwise I'll add some more implementation details.
It look pretty easy on the surface, only experimentation (or a keen eye from one of the other devs) can now show otherwise. It's on my list.
Ross
