The skin will consist of 5 colors (set in the css file) and 3 images (in the top bar). At first I thought, "oh, this will be easy, I just split out where each of the five colors go and replace with the five colors of my choosing" but it looks like the best way to do that is to replace the <link ref=stylesheet (etc)> with an SSI that looks for the cookie, runs the css text through a perl program that will find and replace color1, color2, etc with the appropriate rgb values and serve it up.
Confusions:
I haven't done much with server-side includes (well, I love to echo vars, but that doesn't really count :). My interest in dynamically generating the css file was that I only wanted to maintain one file for both skins. However, it seems like, logically, that I either include the whole file (inside <!-- script --> tags in the header) which completely defeats the purpose of seperate css files, or I need to run my perl find & replace on my end when I update the css source and leave the two as static files. (To clarify, there will be many pages in this website, all using the same styles/skins.) Is that right?
Next problem: when a user moves to another file within my website, is there some way to "tell" the next file to "use this skin" instead of asking for the cookie all over again? I guess I could use an IP "scratchpad". Would that work? Since this particular cookie ONLY regulates the skin there's no need to get fastidious.
Images! The skin involves three images. The images could be included in the css file as background images, but I need the page not to squish below a certain width. If the images are background images, that won't work. (of course, there's the old transparent spacer trick...) Looking for a cookie Yet Again for the same page seems really wasteful. Can I assume that ssi's are executed in order, so that if "blue.css" is the css file linked to, the next little cgi script can read that and decide that it wants blue_top.png? Or will that cause some sort of nasty error? Do I need another scratchpad file?
It seems a lot of skins are accomplished with javascript and I'm trying to avoid that. Any tips or hints you can offer will be heartily appreciated.
Include the header and footer on every page. One thing you might want to look into is sessions, I'm not sure how these are implemented in perl, easy in php, don't think they are available in SSI. Then you could store the selected skin value in the session and call upon that to make your selections.
As far as the blue.css and blue_top.png dead eay I would think. If all of the files are preceded by the name of the sheet you can use that value throughout. Something like
blue.css
blue_top.png
blue_middle.png
blue_side.png
red.css
red_top.png
red_middle.png
red_side.png
and so on, then you just need the colour or name and can build all of the filenames from there.
Plus it looks like PHP will make it easier to introduce some things I am planning to add down the line once the site is established. Thanks!
<link rel=stylesheet type=text/css href=/cgi-bin/style.pl>
style.pl can process any required information...
- Read cookies
- Read settings from database
- Display random styles if you wish :¦
The only thing is, you gotta specify content-type in a print statement:
print "Content-type: text/css\n\n";
print "... your styles go here ...";
You could also include some caching headers, so that it will not load script each time you open a new page.
