forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyriaque Dupoirieux <Cyriaque.Dupoiri...@pcotech.fr>
Subject Re: [jira] Commenté: (FOR-412) use CSS for displaying list of Changes
Date Thu, 27 Apr 2006 15:38:38 GMT
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.
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.
But I don't like the idea to include in the forrest core some the 
definition of the layout of a specific plugin.

In other words :

    * ProjectInfo should not propose resources, but just neutral
      information (in Xdocs or XHTML...)
          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.
    * The idea of this FOR-412 is to avoid this through the use of css
      style - which is much better.
    * 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 ?

Salutations,
Cyriaque,
>
> Then add a match to the plugins input.xmap which reads the existing 
> skinconf.xml file and dynamically adds (using XSL) the additions that 
> the projectInfo plugin needs. The actual entries for the extra-css 
> section should come from some config file resolved via the locationmap 
> as normal, this is where you can provide the ability for the user to 
> override the plugin provided defaults.  
>
> PROBLEM
> =======
>
> 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 
> skinconf.xml this workaround will probably be OK.
>
> PROBLEM 2
> =========
>
> Only one plugin will be able to override things in this way. Again, I 
> have a solution to this in mind, but it requires much more work. Lets 
> worry about it if/when the problem arises since it utilises the 
> forrest.properties.xml code which is not slated for inclusion (or even 
> architectural discussion) until 0.9
>
> Ross
>
>

Mime
View raw message