You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Sjur Moshagen <sj...@mac.com> on 2008/07/04 10:36:46 UTC
pdf plugin config locations
Hello all,
I'm gleaning through past discussions to try to figure out where to
place new config info for the pdf plugin. This relates to my recent
work to move font-family specifications out of the stylesheets.
The questions are:
1. what is the best place to store default values for the plugin?
2. where should the user specify default overrides?
forrest.properties.xml?
Cf. the past discussion about avoiding skinconfig dependencies in the
pdf plugin.
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?
Best regards,
Sjur
Re: pdf plugin config locations
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2008-07-04 at 22:27 +0100, Ross Gardler wrote:
...
> 0.9 we (pending a vote if necessary) plan to deprecate
> forrest.properties and skinconf.xml
AFAIR there is a dependency on forrest.properties by ant itself. At
least the ant we use ATM in forrest. I can remember that the properties
task of ant is not actually working with xml input. However I started a
thread about it and it seems that ant > 1.7 will incorporate it.
http://marc.info/?t=120358552300004&r=1&w=2
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: output.inputModule Plugin dependency
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Mon, 2008-09-01 at 13:40 +0300, Sjur Moshagen wrote:
...
>> I agree with Ross that the easiest solution would be to just move the
>> code to core.
>
> Yeah, it is just one generator. It is fine with me to move this class
> directly to the core, best solution IMO is to leave it in the plugin
> structure but build it by default with the core. Meaning we can drop the
> dependency in the required plugin section.
>
> However ATM I cannot look into the needed changes for that. I am fine
> with either move the class directly to the core or generate the jar once
> and add it to the lib dir. In both cases we need the one match that the
> plugin offers in the main sitemap.
Looks like we have a solution then.
I don't understand the motivation for leaving the code in a plugin but
building it with core, I'm -0 on that.
Easiest solution is certainly just to take the code into core and lose
the plugin, I'm +0 for that.
Ross
Re: output.inputModule Plugin dependency (was: Plugin dependencies)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2008-09-01 at 13:40 +0300, Sjur Moshagen wrote:
> Ross Gardler wrote:
> > Thorsten Scherler wrote:
> >>...
> >>> 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.
> >> The problem I have to drop this functionality as plugin and move it
> >> directly into the core is that cannot build it anymore by itself and
> >> use the resulting jar. However I agree that this plugin represents
> >> core
> >> functionality (that is why I called it infrastructure code).
> >
> > I don't get it? Why is this a problem? Forrest needs the code to go
> > into core. If it builds as a plugin it will build as part of the core.
Yeah! Best solution would be to define it as core plugin and build it
when forrest get build.
> >
> > If you mean that you, as an individual, need to use the code
> > independently of Forrest then I don't think that is a problem for us
> > as a community.
No that is not the problem.
> >
> > On the other hand, if you are saying that this code is useful to
> > many other projects as a standalone peice of code then it should be
> > a project (or more likely a Cocoon block) in its own right. Forrest
> > can then include the block (or jar) from there.
Actually many of our plugins can be used in cocoon directly. Having the
code in a plugin allows everyone to go the "ant local-deploy" route and
use the jar.
> >
> > I'm +1 for the code going into core if it resolves the plugin
> > dependencies in dispatcher and the new PDF work quickly and easily.
> >
> > One day we will need a plugin dependency mechanism (as we always
> > say), but I don't think this is it.
>
> Thorsten has not commented upon this, which means that his problems
> with the plugin code going into core is still unclarified.
>
> I agree with Ross that the easiest solution would be to just move the
> code to core.
Yeah, it is just one generator. It is fine with me to move this class
directly to the core, best solution IMO is to leave it in the plugin
structure but build it by default with the core. Meaning we can drop the
dependency in the required plugin section.
However ATM I cannot look into the needed changes for that. I am fine
with either move the class directly to the core or generate the jar once
and add it to the lib dir. In both cases we need the one match that the
plugin offers in the main sitemap.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: output.inputModule Plugin dependency (was: Plugin dependencies)
Posted by Sjur Moshagen <sj...@mac.com>.
Ross Gardler wrote:
> Thorsten Scherler wrote:
>> On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote:
>>> 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.
>> IMO this observation is correct.
>
> +1
I have seen no other comments on this, thus I take it that we agree
that this is core functionality. -> end of this point of the discussion.
>>> 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.
>> The problem I have to drop this functionality as plugin and move it
>> directly into the core is that cannot build it anymore by itself and
>> use the resulting jar. However I agree that this plugin represents
>> core
>> functionality (that is why I called it infrastructure code).
>
> I don't get it? Why is this a problem? Forrest needs the code to go
> into core. If it builds as a plugin it will build as part of the core.
>
> If you mean that you, as an individual, need to use the code
> independently of Forrest then I don't think that is a problem for us
> as a community.
>
> On the other hand, if you are saying that this code is useful to
> many other projects as a standalone peice of code then it should be
> a project (or more likely a Cocoon block) in its own right. Forrest
> can then include the block (or jar) from there.
>
> I'm +1 for the code going into core if it resolves the plugin
> dependencies in dispatcher and the new PDF work quickly and easily.
>
> One day we will need a plugin dependency mechanism (as we always
> say), but I don't think this is it.
Thorsten has not commented upon this, which means that his problems
with the plugin code going into core is still unclarified.
I agree with Ross that the easiest solution would be to just move the
code to core.
> We accepted plugin dependencies for dispatcher whilst it was in
> whiteboard, however, we have always rejected them in the past for
> very good reasons. Those reasons are in the archives and are not
> limited to version issues.
>
> Unless I've misunderstood the problem with moving the inpuModule
> code into either core or a cocoon block then I'm -1 on using a
> solution that contradicts a previous design decision.
Accepted.
> However, whilst this -1 is resolved I thin it is clear that Sjur
> should proceed with the work using the inputModule - we'll agree a
> way to get it into the next release in parallel with that work.
Ok, thanks, I'll try to continue this week:) (last week was too busy
for me)
Best regards,
Sjur
Re: Plugin dependencies (Was: pdf plugin config locations)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote:
>> Den 21. aug. 2008 kl. 13.09 skrev Tim Williams:
>>
>>> On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <sj...@mac.com> 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.
Correct.
>> 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.
>
> IMO this observation is correct.
+1
>> 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.
>
> The problem I have to drop this functionality as plugin and move it
> directly into the core is that cannot build it anymore by itself and
> use the resulting jar. However I agree that this plugin represents core
> functionality (that is why I called it infrastructure code).
I don't get it? Why is this a problem? Forrest needs the code to go into
core. If it builds as a plugin it will build as part of the core.
If you mean that you, as an individual, need to use the code
independently of Forrest then I don't think that is a problem for us as
a community.
On the other hand, if you are saying that this code is useful to many
other projects as a standalone peice of code then it should be a project
(or more likely a Cocoon block) in its own right. Forrest can then
include the block (or jar) from there.
I'm +1 for the code going into core if it resolves the plugin
dependencies in dispatcher and the new PDF work quickly and easily.
One day we will need a plugin dependency mechanism (as we always say),
but I don't think this is it.
>> 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.
>
> IMO the dependency to the inputModule is totally acceptable, more since
> I doubt that there will be multiple version of this plugin in the
> future.
We accepted plugin dependencies for dispatcher whilst it was in
whiteboard, however, we have always rejected them in the past for very
good reasons. Those reasons are in the archives and are not limited to
version issues.
Unless I've misunderstood the problem with moving the inpuModule code
into either core or a cocoon block then I'm -1 on using a solution that
contradicts a previous design decision.
However, whilst this -1 is resolved I thin it is clear that Sjur should
proceed with the work using the inputModule - we'll agree a way to get
it into the next release in parallel with that work.
Ross
Re: Plugin dependencies (Was: pdf plugin config locations)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote:
> Den 21. aug. 2008 kl. 13.09 skrev Tim Williams:
>
> > On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <sj...@mac.com> 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?
No, IMO no, but as Tim pointed correctly out there have been a lot of
discussion around plugin dependencies.
>
> 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.
IMO this observation is correct.
>
> 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.
The problem I have to drop this functionality as plugin and move it
directly into the core is that cannot build it anymore by itself and
use the resulting jar. However I agree that this plugin represents core
functionality (that is why I called it infrastructure code).
> >>>> 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.
A possible solution would be to use a dependency system like Ivy but the
first integration steps have been stopped.
>
> > 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.
IMO the dependency to the inputModule is totally acceptable, more since
I doubt that there will be multiple version of this plugin in the
future.
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)
Posted by Sjur Moshagen <sj...@mac.com>.
Den 21. aug. 2008 kl. 13.09 skrev Tim Williams:
> On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <sj...@mac.com> 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
Re: Plugin dependencies (Was: pdf plugin config locations)
Posted by Tim Williams <wi...@gmail.com>.
On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <sj...@mac.com> wrote:
> Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler:
>
>>> 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.
>
> 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.
>>> 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.
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:)
--tim
Re: Plugin dependencies (Was: pdf plugin config locations)
Posted by Sjur Moshagen <sj...@mac.com>.
Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler:
>> 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.
Are there other opinions? Do we need a vote before we tie ourselves to
this dependency?
>> 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.
>> 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.
Ok, I'll update the fresh-site file.
>> Comments?
>
> Thanks for looking into this Sjur.
Thanks for the feedback.
Best regards,
Sjur
Re: Plugin dependencies (Was: pdf plugin config locations)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
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
Plugin dependencies (Was: pdf plugin config locations)
Posted by Sjur Moshagen <sj...@mac.com>.
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?
How should it/can it be formalised?
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).
Comments?
Best regards,
Sjur
Re: pdf plugin config locations
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>> Sjur Moshagen wrote:
>>> 1. what is the best place to store default values for the plugin?
>> PLUGIN_HOME/default.plugin.properties.xml
>>
>>> 2. where should the user specify default overrides? forrest.properties.xml?
>> yes.
>>
>> Use a naming convention unique to the plugin, e.g. pdfOutput.fontFamily
>> to avoid naming conflicts
>
> So lets standardise completely at "pluginType.pluginName.property", e.g.
> output.pdf.fontFamily
> internal.dispatcher.caching
> input.projectInfo.project.fullname
>
+1
I've added this note to the issue for documentation of the plugin config
feature. [1]
Ross
[1] https://issues.apache.org/jira/browse/FOR-734
Re: pdf plugin config locations
Posted by Sjur Moshagen <sj...@mac.com>.
Thanks Ross for the thorough reply - it helped a lot:)
Den 5. jul. 2008 kl. 04.38 skrev David Crossley:
> Ross Gardler wrote:
>> Sjur Moshagen wrote:
>>>
>>> 1. what is the best place to store default values for the plugin?
>>
>> PLUGIN_HOME/default.plugin.properties.xml
>>
>>> 2. where should the user specify default overrides?
>>> forrest.properties.xml?
>>
>> yes.
>>
>> Use a naming convention unique to the plugin, e.g.
>> pdfOutput.fontFamily
>> to avoid naming conflicts
>
> So lets standardise completely at "pluginType.pluginName.property",
> e.g.
> output.pdf.fontFamily
> internal.dispatcher.caching
> input.projectInfo.project.fullname
+1
I will use the following:
output.pdf.fontFamily.serif
output.pdf.fontFamily.sansSerif
output.pdf.fontFamily.monospace
There might be use cases where the user wants to have a more fine-
grained control of the font family specified, ie for the different
text types (note, warning, tables, etc), but that is one step further.
I'll first try to make this work.
I'm very soon off for a 4-week vacation - if I don't make it now, I'll
continue afterwards.
Best regards,
Sjur
Re: pdf plugin config locations
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Sjur Moshagen wrote:
> >
> >1. what is the best place to store default values for the plugin?
>
> PLUGIN_HOME/default.plugin.properties.xml
>
> >2. where should the user specify default overrides? forrest.properties.xml?
>
> yes.
>
> Use a naming convention unique to the plugin, e.g. pdfOutput.fontFamily
> to avoid naming conflicts
So lets standardise completely at "pluginType.pluginName.property", e.g.
output.pdf.fontFamily
internal.dispatcher.caching
input.projectInfo.project.fullname
-David
Re: pdf plugin config locations
Posted by Ross Gardler <rg...@apache.org>.
Sjur Moshagen wrote:
> Hello all,
>
> I'm gleaning through past discussions to try to figure out where to
> place new config info for the pdf plugin. This relates to my recent work
> to move font-family specifications out of the stylesheets.
the history was:
0.1 - 0.7 forrest.properties + cocoon.xconf for system config and
skinconf.xml for skin config
0.8 (unofficially) introduced forrest.properties.xml to prevent the need
to edit the cocoon.xconf files when adding new configs and to allow
plugins to provide their own skinning configs
0.9 we (pending a vote if necessary) plan to deprecate
forrest.properties and skinconf.xml
Therefore I suggest:
>
> The questions are:
>
> 1. what is the best place to store default values for the plugin?
PLUGIN_HOME/default.plugin.properties.xml
> 2. where should the user specify default overrides? forrest.properties.xml?
yes.
Use a naming convention unique to the plugin, e.g. pdfOutput.fontFamily
to avoid naming conflicts
> 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.
Ross