forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
Date Thu, 07 Feb 2008 23:36:50 GMT
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

Mime
View raw message