forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sat, 30 Oct 2004 21:34:05 GMT
Thorsten Scherler wrote:
> I have not really had a deep look into our new plugin mechanism but I
> really like the idea of having atomic parts in forrest. Maybe everything 
> that follows is not possible yet but I reckon that it will be. ;-)

My first comment is - exciting!

With the current status of plugins it would not be possible to do this. 
However, in a recent discussion with the two Dave's we came up with the 
idea of plugins having different roles:

- source plugins would manage the creation of source documents (i.e. 
getting out intermediate format)

- intermediate plugins - working with our intermediate format to produce 
the required document (i.e. wholesite.pdf)

- output plugins - creating the output format from intermediate (this is 
where your fo-plugin would fit)

and now...

- skin plugin (as described in this RT)

> I want to use fuctionality contracts that can be hooked up into the
> skin. The contracts should be editable by the user via a skin-property
> file. By editable I mean the user can choose which functionality (s)he
> want to have in the site.
> If we can capsulate the functionalities in sub-plugins the user can even
> add his own functionality without having to write a new skin.

This is an excellent idea, if it can be done (and I am sure we can find 
a way). Lets identify a few use cases and see what we can do.

> The same is true with css-files. The next thing I will implend is an
> overriding mechanism in skinconf.xml for css-files.
> I will extend the <extra-css/> section like this:
> <extra-css>
> <css-override name="branding" src="scale.css">
> </extra-css>

Actually, this is the first use case. Sean and I will need to do this to 
style the Docbook plugins output. I've been avoiding thinking about this 
problem until now. My "hack" solution to get Sean publishing his 
documents was to just place the stuff in skinconf.xml. This would work, 
but would not be elegant.

If the skin plugin can read extra-css info from a plugin installation 
this will solve our problem since there would no longer need to have 
human intervention other than for customisation. If we make the 
skin-plugin ensure that the colours in the extra-css are consistent with 
the main skins then all the better.

> That leads me to generaly override certain parts of the skin. I would 
> like to add an overriding mechanism like this
> <extra-xhtml>
> <!--e.g. some jscripts need to be in the head of the xhtml doc-->

Again, I have a use case for this (see my previous mail "to script or 
not to script". I have a workaround using the iHTML stuff, but something 
prettier than forcing the script into the body of an iHTML page would be 

However, as Nicola said in response to my question about this, Forrest 
is trying to avoid the need for such things. Nevertheless, if it is 
managed carefully (i.e. plugins are marked as static or dynamic) then I 
think it can work.

> This could be used to parse extra parts into the skin in easy way. With 
> that mechanism it will be as well possible to realize that certain parts 
> of the site can be different form other. Trying to say it fuels the 
> individuality of the skin without the need to write xslt-templates.

Looking further ahead, I would like to be able to change this on a per 
page basis. For example, I am working on a WYSIWYG editor, on some pages 
I would like an edit icon, on others I don't want it. With the current 
system I either put it in the skin and so it is on every page or I put 
the icon in the body of all the relevant documents. If I understand your 
proposal correctly we could create some kind of filter that decided 
which pages to place the icon on.

> If somebody wants another design he can 
> implement a css-plugin and add it to his skin. If (s)he wants to have 
> new navigation functionality (s)he is developing a navigation-plugin.

Cool. So you are saying I could use the pelt skin but have a different 
left navigation bar?

Does this RT move us towards having a "portal" like system in which I 
can say OK, on all the pages in this folder I want this RSS news box on 
the right, but on all the ones in this folder I don't want it.

> I think leather should be the first skin that support XHTML2. This way 
> we could use standard xhtml as template language and as well as produced 
>  site output. Maybe leather could use the plain-dev which as well 
> produces XHTML2 and not document2html.xsl.

Given the agreement to move to XHTML2 in 0.7 rather than 0.8 I would say 
regardless of the skin plugin idea leather should be XHTML2.


View raw message