forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [jira] Commenté: (FOR-412) use CSS for displaying list of Changes
Date Thu, 27 Apr 2006 17:04:16 GMT
El jue, 27-04-2006 a las 17:08 +0100, Ross Gardler escribió:
> 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.

Which proposal (or have you not made it yet)? I am confused.

The dispatcher allows every plugin to offer contracts. IMO instead of
having another output plugin (the logical consequence out of: "an input
plugin should not be defining any of the output specific stuff, like
CSS.") we should define this with a css contract. This makes it optional
to use and easy to replace/extend. 

If we extend the structurer matching in the dispatcher lm and add a
mount to plugin specific structurer then every plugin can offer
plugin-specific content/resources via contracts and structrurer.

> 
> > 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.

see above: Which proposal?

> 
> >    * 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.

Yes, but this is the decission to include such a contract or not in the
structurer. I do not see a problem or the difference that a plugin can
*expose* css like gifs. 

...and yes: "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. 

You are talking now with a document-centric view. 
We use the changes-v10 in the projectinfo, right?
The dispatcher allows to define sourcetype specific structurer, where
there is no need to include not images nor css directly to the xdocs. I
further thing it is not a good idea to actually output <img src="..."/>
for add/remove/... That is theme specific. Using ids and class is
sufficient to provide hooks for the theming.

We "just" have to add a plugin location for the
dispacther.structurer.resourceType.* match. Then input plugins can as
well offer source type specific structurer definitions (which always can
be overridden or replaced).

> 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).

the extra-css contract is for the dispatcher branding-css-links.ft
http://localhost:8888/ls.contracts.html#common-branding-css-links

> 
> 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.

In the extra-css or a different place?

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message