Return-Path: 
 <dev-return-23829-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 2053 invoked from network); 26 Apr 2006 12:50:55 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 26 Apr 2006 12:50:55 -0000
Received: (qmail 95721 invoked by uid 500); 26 Apr 2006 12:50:54 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 95686 invoked by uid 500); 26 Apr 2006 12:50:54 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 95675 invoked by uid 99); 26 Apr 2006 12:50:54 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Apr 2006 05:50:54 -0700
X-ASF-Spam-Status: No, hits=1.5 required=10.0
	tests=SUBJECT_ENCODED_TWICE
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [212.23.3.142] (HELO rutherford.zen.co.uk) (212.23.3.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Apr 2006 05:50:53 -0700
Received: from [82.69.78.226] (helo=[192.168.0.2])
	by rutherford.zen.co.uk with esmtp (Exim 4.34)
	id 1FYjTU-0004bu-0V
	for dev@forrest.apache.org; Wed, 26 Apr 2006 12:50:32 +0000
Message-ID: <444F6C8C.8080708@apache.org>
Date: Wed, 26 Apr 2006 13:50:20 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: [jira] =?UTF-8?B?Q29tbWVudMOpOiAoRk9SLTQxMikgdXNlIENTUyBmb3Ig?=
 =?UTF-8?B?ZGlzcGxheWluZyBsaXN0IG9mIENoYW5nZXM=?=
References: <70044518.1146044283204.JavaMail.root@brutus>
 <444F42D8.6000803@apache.org> <444F4870.3070201@pcotech.fr>
In-Reply-To: <444F4870.3070201@pcotech.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-Rutherford-IP: [82.69.78.226]
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Cyriaque Dupoirieux wrote:
> le 26/04/2006 11:52 Ross Gardler a =C3=A9crit :
>=20
>> Cyriaque Dupoirieux (JIRA) wrote:
>>
>>>     [=20
>>> http://issues.apache.org/jira/browse/FOR-412?page=3Dcomments#action_1=
2376446=20
>>> ]
>>> Cyriaque Dupoirieux commented on FOR-412:
>>> -----------------------------------------
>>>
>>> The best way to do this should be to have a specific resource=20
>>> projectInfo.css - find via the lm -
>>> Does anyone know how to use a specific resource with an input plugin =
?
>>
>>
>> I don't quite understand the question, can you explain exactly what=20
>> you mean by "specific resource with an input plugin"?
>=20
> I mean that projectInfo specific styles should not appear in a standard=
=20
> forrest css file, but in a specific one which will be find with a good =

> match in the projectInfo location map (with a fallback mecanism in orde=
r=20
> to let the customer override it) and only included in the pages=20
> generated by this plugin.
> (Don't know if I am clear enough ?)

Yep, very clear.

There is no existing approach to this, but I think there are a number of =

potential solutions. First, lets notice that it is much easier to do=20
this in the dispatcher than with skins. Therefore, the solution I=20
propose below is a quick solution that should work (not tested) with=20
minimal effort. I've noted a couple of problems with this approach at=20
the end of the mail.

What we need to do is dynamically insert something into skinconf.xml. We =

therefore need to intercept the request for skinconf.xml, i.e. add a=20
plugin locationmap entry of:

     <match pattern=3D"project.skinconf">
         <location src=3D"cocoon://projectInfo.skinconf" />
     </match>

Then add a match to the plugins input.xmap which reads the existing=20
skinconf.xml file and dynamically adds (using XSL) the additions that=20
the projectInfo plugin needs. The actual entries for the extra-css=20
section should come from some config file resolved via the locationmap=20
as normal, this is where you can provide the ability for the user to=20
override the plugin provided defaults.

PROBLEM
=3D=3D=3D=3D=3D=3D=3D

We will have to define the location of the original skinconf file in the =

input.xmap, we will not be able to retrieve it via the locationmap since =

this will put us into a loop.

I have a solution in mind, but since dispatcher is proposing to remove=20
skinconf.xml this workaround will probably be OK.

PROBLEM 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Only one plugin will be able to override things in this way. Again, I=20
have a solution to this in mind, but it requires much more work. Lets=20
worry about it if/when the problem arises since it utilises the=20
forrest.properties.xml code which is not slated for inclusion (or even=20
architectural discussion) until 0.9

Ross