On Sun, 2005-05-22 at 12:59 +0100, Ross Gardler wrote: > 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. >
Jumping in right here, with other words that means that in your Shakespeare you have some kind of markup to state which paragraph or sentence should go into the directors output and which in the actor versions, right? Maybe something like <p class="dirCut">...</p> <p class="actorCut">...</p> > 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? > That leads use to the logic:tag that I mentioned the other day (ross was talking about role specific views and I mentioned this logic tags - maybe somebody can provide a link I could not found it). In my recent RT you can find: xmlns:logic="http://apache.org/forrest/logic/1.0"; I used this in the inx plugin to make a decision what contract to include based on parameters (or bean properties). The actual use-case was that a catalog can either have 4 or 8 page and the processing had some marginal differences. Here is a snippet demonstrating this: <forrest:hook name="page" count="4"> <logic:lastPage value="4"> <forrest:contract type="img" name="top-image-bit-last" objectId="411"/> <forrest:contract type="txt" name="footer-l-text" objectId="441"/> </logic:lastPage> <logic:lastPage value="8"> <forrest:contract type="img" name="top-image-bit" objectId="411"/> <forrest:contract type="txt" name="footer-r-text" objectId="441"/> </logic:lastPage> <forrest:fbits name="infobits" count="4"/> </forrest:hook> This could be used for marginal differences in the page. If the processing or the containing contracts are very different something like the following I reckon would be more appropriate: <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"; xmlns:logic="http://apache.org/forrest/logic/1.0";> <logic:filter value="dirCut" parameter="p"> <forrest:view format="inx" /> </logic:filter> <logic:filter value="actorCut" parameter="p"> <forrest:view format="inx" /> </logic:filter> I just altered the logic tag. Like I stated as well in RT the inx plugin still has some specific business logic. The logic:lastPage is an example. Better would be something more generic like <logic:filter value="" parameter=""/>. > > 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, > +1 > > I would define it in a plugin > configuration. > If you consider the view as config. +1 > > 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 would do like above mentioned with Shakespeare. Thing about the content writer (s)he will know where the content belongs. ...and content writer != admin (site.xml) > > > 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 > Yes, Ross is right: http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs/docs/TR/2004/WD-forrest10.html Step 3: Filtering (content) Actually the filtering should IMO happen and controlled in the view dispatcher (configured by the *.fv). It is part of the dispatcherView concept. Actually filtering IMO is part of my recent RT. The filtering should further be done by simple logic matches that define conditions that have to be matched to display the content (or better said contract). The filter of <document href="ssp_with_forrest.s5.html" filter="cleanSlides.xsl"/> is per definition (my personal) a contract because it is processing special parts of the content. To capsule the filter="cleanSlides.xsl" within a contact makes is easier to reuse and define new ones in different views. The view is (can be) document specific that means IMO the filtering *has to* be part of the view package. Here you define which business and view helper are needed. The filtering stage is within the business helper part of the dispatcher view pattern. WDYT? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
