On Tue, 2005-10-18 at 10:27 +0200, Thorsten Scherler wrote: > Kevin, very cool.
Thanks > 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 window.onload=init 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? > > > http://www.kegcl.demon.co.uk/forrest/index.html > > > > 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 forrest.properties to get views (v1) working. Can be dropped on forrest seed-basic but cp site-basic.xml site.xml Kevin > Thanks > > salu2
contrib.tar.gz
Description: application/compressed-tar
