forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [jira] Commenté: (FOR-412) use CSS for displaying list of Changes
Date Thu, 27 Apr 2006 16:08:52 GMT
Cyriaque Dupoirieux wrote:
> le 26/04/2006 14:50 Ross Gardler a écrit :
> 
>> Cyriaque Dupoirieux wrote:
>>
>>> le 26/04/2006 11:52 Ross Gardler a écrit :
>>>
>>>> Cyriaque Dupoirieux (JIRA) wrote:
>>>>
>>>>>     [ 
>>>>> http://issues.apache.org/jira/browse/FOR-412?page=comments#action_12376446

>>>>> ]
>>>>> Cyriaque Dupoirieux commented on FOR-412:
>>>>> -----------------------------------------
>>>>>
>>>>> The best way to do this should be to have a specific resource 
>>>>> 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 
>>>> you mean by "specific resource with an input plugin"?
>>>
>>>
>>> I mean that projectInfo specific styles should not appear in a 
>>> standard 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 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.
> 
> Not quite sure, let's follow...
> 
>>
>> 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 this in the dispatcher than with skins. Therefore, the solution I 
>> propose below is a quick solution that should work (not tested) with 
>> 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="project.skinconf">
>>         <location src="cocoon://projectInfo.skinconf" />
>>     </match>
> 
> 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 
stuff, like CSS. That is the job of the skin system. My proposal is a 
way of allowing an input plugin to pass information to the final 
skinning/theming stage.

> I know it's not very nice because we define a specific output - which is 
> 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 
> definition of the layout of a specific plugin.

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

> In other words :
> 
>    * 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 
core. I don't think you were around way back then, but projectInfo was 
originally totally core stuff, the images must be leftovers from the 
move, I think it was the first code I ever extracted from core into a 
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 
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 
structure. They would need to be exposed via the locationmap and sitemap 
appropriately. For example (below is untested, but I'm pretty sure it 
will work):

For image:

/resource/images/add.gif

In XDoc:

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

In resources.xmap of projectInfo plugin:

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

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

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

And now for the No part...

CSS is different, it is not content but is instead style information 
that needs to be embedded in the final output stage. This is something 
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="..."/> 
for including CSS, nor should there be since this is not content. The 
mechanism we have for extending the forrest defined skins is extra-css 
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 
of little tweaks to embed the CSS supplied by the projectInfo plugin in 
skinconf.xml so that it will make its way through to the final output stage.

So, did I understand you, or am I addressing something completely different?

Ross


Mime
View raw message