forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: Plugin dependencies (Was: pdf plugin config locations)
Date Thu, 21 Aug 2008 07:06:35 GMT
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


Mime
View raw message