forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sat, 30 Oct 2004 20:28:19 GMT
Hello devs,

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

The idea is to move the skins into a plugin like the
plugin. BTW I reckon we have to capsulate the pdf into a plugin for its
own. IMO it should be not in the skin. IMO this part will need some
loving care in the future. ;-) I reckon we can call it fo-plugin.

The skin-plugin should be the main plugin for all skin related issues. 
It is what I would refer to as top level plugin that can host different 
sub-plugins. This way it should be possible to reuse our 
skin-functinality even better and more efficient.

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.

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:
<css-override name="branding" src="scale.css">

That makes it easy to provide his one
|-- base-contracts.css
|-- basic.css
|-- branding.css
|-- navigation.css
`-- profiling.css.xslt

Actually saying this a css-plugin for leather would contain this files.

That leads me to generaly override certain parts of the skin. I would 
like to add an overriding mechanism like this

<!--e.g. some jscripts need to be in the head of the xhtml doc-->
    <css-override name="branding" src="scale.css">
<!--e.g. some jscripts need to be in the body-->

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.

Like I stated before "leather" [1] will be the common base for "corium". 
I want to use everything that I want to implemend into leather implement 
as skin-plugins. That makes it possible to reuse the code copyless. That 
will help us to develope Corium. 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.

Corium should be the skin that is absolute costumizable. It should be 
like a skin configuration dealer that supports different skin 
distribution provider.

The first provider would be leather with his default set of components:
leather =
functionality (e.g. pelt++ - old functionality from pelt and new ones)
+ css (e.g. scale - the one Shaun mentioned) +
+ skelleton (e.g. nc - naming convention)

This different component could be different for every skin distribution 
provider. The provider only have to keep this information
a) functions
b) css
c) skellton

That makes it easy to offer the personal skin *without* writing (copy n' 
paste) a new skin and change only some functions, css and skellton 
elements. Even better we can use the #forrest.skins.descriptors approch 
for that. :)

I started to write this thread and then saw Ross mail "A last ditch 
attempt to encourage an obviously capable developer"
 > As a project we have committed to move to XHTML2. I was hoping that your
 > work would help myself and others drive that forward (in fact it has see
 > Nicola Kens RT).

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.



View raw message