Thorsten Scherler wrote:
On Wed, 2008-02-06 at 08:20 +0000, Ross Gardler wrote:
Thorsten Scherler wrote:
On Tue, 2008-02-05 at 03:49 +0100, Ferdinand Soethe wrote:
If I understand you correctly I would have to add that
pipeline to the plugins sitemap so that it looks for
skinconf settings elsewhere and than what?
Not exactly, it was more an example for the generator.
Where and how would I have to store the settings formerly in
skinconf?
In forrest.properties or forrest.properties.xml. That would mean to
flatten some
<pdf>
...
<page size="letter" orientation="portrait" text-align="left"/>
into e.g. forrest.properties.xml:
<properties>
<property name="pdf.page.size" value="letter"/>
<property name="pdf.page.orientation" value="portrait"/>
<property name="pdf.page.text-align" value="left"/>
...
-1
This change makes any project using 0.3 PDF plugin incompatible with 0.2
(if the user has changed any of the skinconf properties).
The user would need to update/migrate/implement this changes to the
properties file (and only this changes since we are using fallbacks in
properties). I reckon we are talking about a couple of this changes but
I reckon in most case even less.
It is an inconvenience to the user which brings no benefit other than
behind the scenes. The question is therefore do we want tc inconvenience
users without documented warnings?
It also makes it really confusing as to where properties are stored in
0.9 As far as I remember we only use skinconf for core plugins.
Why are we using skinconf for core plugins? The only plugin that should
use skinconf is a skin plugin (if it would exist)!
I'm not against breaking the dependency. I'm only against doing it in
0.3 PDF plugin, released for Forrest 0.8, without warning or good reason.
Further we decided to introduce the properties system after 0.8 as
configuration system AFAIR, meaning there is no confusion regarding in
where to store properties.
Yes, that's my point. Your proposal introduces the properties to a
plugin for Forrest 0.8 which does *not* use the new system.
To make this change in a core plugin I think we need to lose skinconf
altogether and this will delay the release of the 0.3 PDF plugin
considerably.
Didn't we decided that plugins have an independent release cycle from
core, or am I confusing this with cocoon 2.2 blocks?
We did agree that.
But, see my comment above this is a feature of Forrest 0.9 and you want
to use it in a 0.8 plugin.
Further I do not see the need that we need to loose skinconf altogether
BEFORE the plugin can be released (I totally agree that we need to drop
skinconf).
I withdraw that assertion.
My -1 stands for the reasons above.
We should deprecate skinconf in PDF 0.3 and remove it in 0.4.
Ross
