Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4450EC94.50806@apache.org>
Date: Thu, 27 Apr 2006 17:08:52 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
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>
 <444F6C8C.8080708@apache.org> <4450E57E.3030800@pcotech.fr>
In-Reply-To: <4450E57E.3030800@pcotech.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Cyriaque Dupoirieux wrote:
> le 26/04/2006 14:50 Ross Gardler a =C3=A9crit :
>=20
>> Cyriaque Dupoirieux wrote:
>>
>>> le 26/04/2006 11:52 Ross Gardler a =C3=A9crit :
>>>
>>>> Cyriaque Dupoirieux (JIRA) wrote:
>>>>
>>>>>     [=20
>>>>> http://issues.apache.org/jira/browse/FOR-412?page=3Dcomments#action=
_12376446=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 plugi=
n ?
>>>>
>>>>
>>>>
>>>> I don't quite understand the question, can you explain exactly what =

>>>> you mean by "specific resource with an input plugin"?
>>>
>>>
>>> I mean that projectInfo specific styles should not appear in a=20
>>> standard forrest css file, but in a specific one which will be find=20
>>> with a good match in the projectInfo location map (with a fallback=20
>>> mecanism in order to let the customer override it) and only included =

>>> in the pages generated by this plugin.
>>> (Don't know if I am clear enough ?)
>>
>>
>> Yep, very clear.
>=20
> Not quite sure, let's follow...
>=20
>>
>> 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=20
>> do 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 =

>> 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 plugin locationmap entry of:
>>
>>     <match pattern=3D"project.skinconf">
>>         <location src=3D"cocoon://projectInfo.skinconf" />
>>     </match>
>=20
> Our problem is more to use a specific resource - such as a stylesheets =

> file ie. projectIcon.css - and not use a specific skinconf.

Well an input plugin should not be defining any of the output specific=20
stuff, like CSS. That is the job of the skin system. My proposal is a=20
way of allowing an input plugin to pass information to the final=20
skinning/theming stage.

> I know it's not very nice because we define a specific output - which i=
s=20
> our css file - to define the layout of the ProjectInfo page - which is =

> an input plugin.

Exactly...

> But I don't like the idea to include in the forrest core some the=20
> definition of the layout of a specific plugin.

I totally agree. There should be complete separation between core and=20
plugins.

> In other words :
>=20
>    * ProjectInfo should not propose resources, but just neutral
>      information (in Xdocs or XHTML...)

Agreed

>          o Which is not the case today because the plugin generate a
>            use of pictures such as add.gif. And he doesn't supply these=

>            resources which are stored in the core.

That is an oversight on the extraction of the projectInfo stuff from=20
core. I don't think you were around way back then, but projectInfo was=20
originally totally core stuff, the images must be leftovers from the=20
move, I think it was the first code I ever extracted from core into a=20
plugin.

>    * The idea of this FOR-412 is to avoid this through the use of css
>      style - which is much better.

I don't understand what you are suggesting here. My proposal provided a=20
mechanism for using CSS, just as you suggest.

>    * Now the question : Does a plugin using resources also supply
>      default resources (add.gif or projectInfo.css...) or not ?
>          o If he supplies default, how ?
>          o If he doesn't - so what ?

Yes, and No...

Yes, a plugin can (and should) provide its own *content* resources, such =

as gifs. These should be provided via the resources/ directory=20
structure. They would need to be exposed via the locationmap and sitemap =

appropriately. For example (below is untested, but I'm pretty sure it=20
will work):

For image:

/resource/images/add.gif

In XDoc:

<img src=3D"projectInfoPlugin/images/add.gif"/>

In resources.xmap of projectInfo plugin:

<map:match pattern=3D"projectInfoPlugin/images/**.gif"/>
   <map:read src=3D"lm:projectInfo.image.{1}.gif"/>
</map:match/>

In locationmap of projectInfo plugin (optionally overwritten in project=20
lcoationmap):

<match pattern=3D"projectInfo.image.**">
   <location src=3D"resources/images/{1}"/>
</match>

And now for the No part...

CSS is different, it is not content but is instead style information=20
that needs to be embedded in the final output stage. This is something=20
that cannot, and should not, be done by anything other than the skinning =

or themer stage.

There is, as far as I remember, no XDoc equivalent of <img src=3D"..."/> =

for including CSS, nor should there be since this is not content. The=20
mechanism we have for extending the forrest defined skins is extra-css=20
in skinconf.xml. Thus we end up at my proposal again (and the dispatcher =

of course).

My proposal was only the same as above, but the xmap part had a couple=20
of little tweaks to embed the CSS supplied by the projectInfo plugin in=20
skinconf.xml so that it will make its way through to the final output sta=
ge.

So, did I understand you, or am I addressing something completely differe=
nt?

Ross