forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Views (v1) - a user attempt
Date Tue, 18 Oct 2005 08:27:27 GMT
Kevin, very cool. 

This contract is exactly what was missing to show the power of views. :)
Would you like to commit it back to views.

(more inline)

El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
> Thought I'd post my work in progress in trying to do switchable
> alternate css stylesheets. I call it theme switching though not
> sure if that is the correct terminology.

maybe: branding-theme-switcher.ft

> I've put four theme links at the bottom of the left bar home tab,
> each setting an alternate stylesheet. In doing this I used a Perl
> template system to generate my alternate css files based on three
> colors and three contrasting text colors.
> While doing this it reminded me of the old skinconf with defined
> colors that were used as parameters to an xslt to create one
> css file. It got me thinking that Forrest could generate alternate
> css files then perhaps have a contract that would emulate the
> <forrest:css ...> tag in view files and insert all the required
> alternate css files. Perhaps even part of something like the
> publishedstrip contract to add the links to click to switch the
> themes rather than what I have done in site.xml at the moment.

NOTE: the structurer do not use the skinconf.xml anymore!

Actually the skinconf colors can be brought back quite easy. I never
forgot them, but on the archive you may find some mails from other devs
that do not wanted that anymore, so I did not prioritized them. Anyway,
it would be awesome to pass the colors into the contract from the view. 

That leads to another contract that I want to create. genericCss.ft,
which will bring back the extra-css from the skinconf.xml back. It would
just take the css definition from the view and pass them into an inline
css. More or less the same could be done with the colors from the old

> Anyway I'm probably way off track about what the new theme
> plugin will allow users to do driven off config' parameters.

jeje, no. The v2 has to be configured totally by the view (no default
beside the fallback are given). You are right on track with the approach
I took in v2.

> Anyone with a slow dial up? Do you see an unacceptable problem
> if pages aren't cached after choosing another theme other than
> the default 'dull' theme?


Can you can up with a patch that I can use to integrate this really nice
feature into v2? Like I said above it is awesome to show off what you
can do with views.



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

View raw message