Re: Plugin dependencies (Was: pdf plugin config locations)
On Wed, 2008-08-20 at 14:52 +0300, Sjur Moshagen wrote: Den 5. jul. 2008 kl. 00.27 skrev Ross Gardler: Have I understood correctly that whatever the location, the config info will be available in the relevant stylesheet as child elements of a /config/ element on the top document level? There are two ways of gaining access to the properties. The original way I implemented is by passing them in via the sitemap using properties:pdfOutput:fontfamily}. This technique can be seen in the daisy input plugin for example. Later Thorsten implemented the o.a.f.p.output.inputModule to allow all properties to be pulled together into a single file. Using the dispatcher you can do cocoon://module.properties.properties and have all properties returned (at leat I think that's how it works, I've never used it this way myself). In the dispatcher cocoon://skinconf.xml returns the same as cocoon://module.properties.properties. So, in order to make all properties available in your stylesheets aggregate the output of cocoon://module.properties.properties with the source document. Personally, I'd add the properties using the first method as it would be more efficient. But if you have too many then the latter method is good (if worried about efficiency make it a caching pipeline and use an XSLT to filer out unwanted properties. The first implementation only included three properties: output.pdf.fontFamily.serif output.pdf.fontFamily.sansSerif output.pdf.fontFamily.monospace I made these available using the first approach Ross described above, ie passing them in via the sitemap as xsl parameters. But as I indicated later in this thread, one can easily imagine the need for more finegrained control of font family usage. I have now reworked my implementation to allow any of the present font-family specifications to be individually specified by the user on a per- project basis. But the list is now quite long (defaults in parenthesis): output.pdf.fontFamily.rootFontFamily (serif) output.pdf.fontFamily.firstFooterFontFamily (sans-serif) output.pdf.fontFamily.evenHeaderFontFamily(sans-serif) output.pdf.fontFamily.evenFooterFontFamily(sans-serif) output.pdf.fontFamily.oddHeaderFontFamily (sans-serif) output.pdf.fontFamily.oddFooterFontFamily (sans-serif) output.pdf.fontFamily.documentTitleFontFamily (sans-serif) output.pdf.fontFamily.versionFontFamily (sans-serif) output.pdf.fontFamily.authorsFontFamily (sans-serif) output.pdf.fontFamily.TOCFontFamily (sans-serif) output.pdf.fontFamily.sectionTitleFontFamily (sans-serif) output.pdf.fontFamily.sourceFontFamily(monospace) output.pdf.fontFamily.codeFontFamily (monospace) output.pdf.fontFamily.warningTitleFontFamily (sans-serif) output.pdf.fontFamily.noteTitleFontFamily (sans-serif) output.pdf.fontFamily.fixmeTitleFontFamily(sans-serif) That is, 16 properties all in all (they all fall back to the indicated defaults, which means one can specify only the three base font families, and/or individually override any of the above). This makes the sitemap+parameter solution very clumsy, and hard to maintain. Thus solution two (aggregation) seems the most elegant. BUT: this creates a dependency between the o.a.f.p.output.pdf and o.a.f.p.output.inputModule - no pdf files will be generated if the output.inputModule is not listed in the required plugins list. Instead, one will get an error message that the pdf file could not be found (really: the aggregation did not succeed because the cocoon:// module.properties.properties source didn't match anything). QUESTIONS: Is this dependency acceptable? IMO yes, since the plugin is very small and thought a infrastructure code. Like you describe the alternative to implement it in the sitemap is cumbersome to maintain. How should it/can it be formalised? Not sure what you mean? At least we need to update the seeds to include the o.a.f.p.output.inputModule as well as the pdf plugin (new seeds only include the pdf plugin). As I understand it you commit to the fresh-site forrest.properties files (skins/dispatcher) and the cron is doing the rest. Comments? Thanks for looking into this Sjur. salu2 Best regards, Sjur -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Plugin dependencies (Was: pdf plugin config locations)
Den 21. aug. 2008 kl. 13.09 skrev Tim Williams: On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen [EMAIL PROTECTED] wrote: Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler: Is this dependency acceptable? IMO yes, since the plugin is very small and thought a infrastructure code. Like you describe the alternative to implement it in the sitemap is cumbersome to maintain. Are there other opinions? Do we need a vote before we tie ourselves to this dependency? In the past I think we've consistently decided against having dependent plugins until we have a facility built in that will manage them properly. I reckon this is due to version incompatibility problems between plugins, etc. The dispatcher plugin is already dependent upon the o.a.f.p.output.inputModule, although dispatcher is in the whiteboard. Would this dependency stop it from being released from whiteboard? What it looks like to me, is that the o.a.f.p.output.inputModule is turning into core functionality of Forrest (and necessarily so if we do away with skinconfig), cf the comments from Thorsten earlier in this thread. Either we accept this fact, but leave the functionality as a (required) plugin, or we move the functionality of the o.a.f.p.output.inputModule into the Forrest core. Then we would have no dependency anymore, since core is allways there. How should it/can it be formalised? Not sure what you mean? Whether it is possible to formalize the dependency, such that if the pdf plugin is specified, forrest will automatically also include other plugins the pdf plugin is dependent on. But if I remember past discussions correctly, this isn't possible yet. It is not and I believe this is the issue. There's no way for plugin A to say I require version N of plugin B, for example. Complicating matters, if you have two plugins with dependencies on differing versions of the same plugin, strange things are likely to happen. I believe it's this complication (the devils in the details) that has kept us from having such a capability for so long. Understandable, and I have no real solution to this. I'm not saying we shouldn't change the status quo but I think it's worthy of some discussion first. Having said that, you seem to be on a good roll and I don't want long discussion to slow you down either:) :D I have now done the basic work for skins-based sites, but I will have to do the same for dispatcher-based sites as well (otherwise the pdf plugin would be broken in dispatcher), which means there is still some time to discuss this before I commit. If we decide against the dependency, my changes will still work, but forwarding the user settings to the xsl stylesheet will be much more clumsier and hard to maintain. Best regards, Sjur
