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)
