Ferdinand Soethe wrote:
Working on our presentation for ApacheCon, Ross and I have the problem
that the presentation contains a lot of internal info and also some
that should only be part of someversions (speaker version, slide
version, printed notes).
They are marked up with class attributes, so filtering is possible,
the question is where.
And since filtering might vary on a per document basis, I was
wondering whether we could have a filtering plugin that can be applied
before any other output plugin and apply the filtering needed.
Interesting.
This allows us to define a different versions of the content of a page.
That is some content will not be displayed. I actually have another use
case for this. I have the full works of Shakespeare ,marked up as XML, I
want to be able to provide directors output (stage directions, and
director notes), actor versions (dialogue and actor cues) etc.
However, since this is only an extension to the skin I suspect there
will be considerable overlap with Thorstens work on views. Thorsten, any
comments on how this would overlap with your vision for Forrest:views?
Ideally the criteria would be defined in the site element.
So instead of my current version (that opens the presentation as a
normal Forrest document as well as an s5-slideshow)
<apachecon label="ApacheCon">
<slides label="slides" href="s5slides/ssp_with_forrest.html"/>
<slides label="document" href="ssp_with_forrest.html"/>
</apachecon>
I could then have
<apachecon label="ApacheCon">
<slides label="Slides" href="s5slides/ssp_with_forrest.html"
filter="cleanSlides.xsl"/>
<slides label="Slides" href="s5slides/ssp_with_forrest.html"
filter="speakerSlides.xsl"/>
<slides label="document" href="ssp_with_forrest.html"
filter="printedVersion.xsl"/>
</apachecon>
where the xsl-files contain the desired filter.
I wouldn't define it in site.xml, I would define it in a plugin
configuration. For example:
<filters>
<document href="ssp_with_forrest.s5.html" filter="cleanSlides.xsl"/>
<document href="ssp_with_forrest.s5.html" filter="speakerSlides.xsl"/>
...
</filters>
(NOTE my change to using the s5.html extension is planned for the s5
plugin and becomes necessary to achieve the following)
The reasons for having it in a config file are numersous:
1) a plugin cannot mess with an internal format DTD (we don't currently
have one for site.xml so at present that's not a problem, but if we did
go that way it would be)
2) it would allow us to provide more granular control over the filters
3) It would allow filter chains.
For example:
<filters>
<document href="**.s5.html" filter="stripDetail.xsl"/>
<document href="speaker.s5.html" filter="speakerSlides.xsl"/>
...
</filters>
I first wanted to create this as output plugin, but since all there is
is custom xsl which can be different for each file, I didn't think
this would made a lot of sense.
This would not be an output plugin. The reason being that this
processing *has* to occur at a specific point in the pipeline, i.e.
after conversion to XDoc and before skinning, output plugins come after
the skinning stage. Consequently, this proposal would have to override
some of the core pipelines in Forrest, hence it is an Internal plugin
(that's the clearest definiiton yet of what an Internal plugin is, I think).
Ross
