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
