forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sun, 31 Oct 2004 17:33:34 GMT
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>> Thorsten Scherler wrote:
> <snip/>
>>> 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.
>> Wait a second, we already have this, but it's not called plugin.
>> Every skin can make it's *own* fo (->PDF) output stylesheets, and is 
>> not found it uses the common templates. How is this lacking now?
> I think Thorsten is proposing that we should be able to replace the PDF 
> portion of a skin without the need to copy over the XHTML portion 
> (admittedly the XHTML portion would be a series of xsl:includes but it 
> still requires work).

Hmmm, does not seem so important to warrant a change of this size.
Let's read on...

>>> 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-->
>>>  <xhead>
>>>   <xscripts/>
>>>   <extra-css>
>>>    <css-override name="branding" src="scale.css">
>>>   </extra-css>
>>>  <xhead>
>>> <!--e.g. some jscripts need to be in the body-->
>>>  <xbody>
>>>   <xscripts/>
>>>  </xbody>
>>> </extra-xhtml>
>>> 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.
>> Hmmm, recreating XSLT?
> I read this differently, to me it says "enabling *users* to insert stuff 
> into their generated pages without the need to edit XSLT". For example, 
> WYSIWYG editing scripts could be inserted into the <xscripts> element. 
> This is even more powerful if I can provide a regular expression stating 
> which pages it should/should not be inserted into.
> From a non-dynamic perspective, how about inserting some meta tags that 
> Forrest does not currently support.

IMHO these should be insertions defined in skinconf - see the newly 
proposed format - . Other than that I don't see this flezibility much 

>>> 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. :)
>> Have you not tried the current system?
> Yes, and I do not believe it is as flexible as Thorsten is proposing. 
> Currently if I want to add a footer to my PDF files I have to copy a 
> whole skin and edit the FO XSL's. With Thorstens proposal I would simply 
> need to edit a FO skin-plugin and not touch the XHTML portion. From a 
> users perspective I think this makes things much easier, from a dev 
> perspective it means I don't have to keep my slightly modified skin in 
> sync with the developments here in Forrest.

Hmmm, I don't see it as a compelling use case, and it mixes 
functionality with style.

Actually, I have not read what I would regard a positive note of his 
proposal, which is the unification of plugins and skins in a single system.

I am not against it, but do not yet see the advantages.

I would propose that we discuss in the following days the whole internal 
structure of the processing, and insert the skin discussion in there.
In any case, if someone wants to build a working example of the above in 
a plugin or branch, please feel free to do so. It would be something 
concrete to see and decide upon.

I'm now finishing looking into the sitemaps before starting a mega RT to 
restructure the Forrest internals. Stay tuned :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message