forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin <>
Subject Re: Views (v1) - a user attempt
Date Tue, 18 Oct 2005 14:09:42 GMT
On Tue, 2005-10-18 at 10:27 +0200, Thorsten Scherler wrote: 
> 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.

Yes. I will sort something out. Though what I have done in
generating the alternate css files is outside of Forrest
using a Perl template system. Not maintainable applying one
say IE bug fix to five css files.

The contact is a simple javascript that used
to read a cookie and set the alternate css.

I had to patch internal.view prepare.xhtml.xsl
to remove <body onload=init()>

Side note: multiple javascript contracts using init? 

I changed nav-main.ft slightly too. Couldn't remove the
gap between main tabs within <ul><li>...

> (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. 

Sounds good. In views (v2) as a view still a collection of contracts?

> 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
> skinconf.
> > 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.

Glad I'm on the right track.

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

Attached file. Drop on a fresh forrest seed and
edit to get views (v1) working. 

Can be dropped on forrest seed-basic but
cp site-basic.xml site.xml 


> Thanks
> salu2

View raw message