[PHPiCalendar-DEV] Preferences and css

[Jim Hu <ji...@ta...>]

Wes,

The cpath problem was that if I went to preferences from a view where  
cpath was defined, I would see a list of the calendars there...but if  
I selected one it would set the cookie to look for that calendar in  
the default calendar path.  So it wasn't possible to actually set a  
preference for a calendar below there and then have phpicalendar go  
there.   Thinking about it, the preferences should use the multi- 
picker, not the pulldown.  Have to think about what that means for  
the cookie, though, and how it would be passed back to  
ical_parser....what I'd really like is a way to have webcals that  
don't appear by default, but are available for users to pick in  
combination.  Can we do that already?  Maybe I'll play with that idea...

You're probably right about the css...although in principle we could  
make a really elaborate cookie to set the colors and background  
pattern.  That wouldn't be too hard. But do users want that?  Do  
admins?  Probably not.  I should just make it into a utility to make  
css files for admins to use.  In which case the controls should be  
more sophisticated.

Jim

> Message: 4
> From: Wesley Miaw <we...@we...>
> Subject: Re: [PHPiCalendar-DEV] Some fixes for preferences
> Date: Sun, 27 Nov 2005 10:24:36 -0800
> To: php...@li...
> Reply-To: php...@li...
>
> Hi Jim,
>
>> 2. the usual problems with $cpath.  I added cpath to the cookie,
>> but it is not settable by the user in preferences...it's a hidden
>> parameter for now.
>
> What sort of problems are cpath causing for you?
>
> About the calendar colors, I guess if people have a real use for
> allowing their visitors to choose a color scheme, that's a nice
> feature to have. I'm not sure there's any value in having the CSS be
> dynamically generated if you can't actually enter in your own colors
> in the preferences page though. Seems as though since the choices are
> static, simply making sure the templates contain the right CSS
> references and then having a choice of which CSS page to load would
> serve the same function, and result in less runtime overhead.
>
> I guess I'm just saying that the script to write out your CSS color
> choices is good, but I think it would be better to output to a file
> for inclusion, instead of generating inline CSS every time based on
> the contents of a PHP configuration file.
>
> This would make it easier for people who know CSS but don't know PHP
> (although I'm sure your CSS config file isn't that complicated) and
> remove the code hit, which is quite small to begin with. You could
> also make it so the preference choices are the names of whatever CSS
> files are available in a special directory. This would also ensure
> that no one is confused as to why CSS information is showing up from
> two different sources, instead of one. Well, maybe that's not good
> either, because then you'll be duplicating a lot of common CSS
> definitions.
>
> Is there a precedence order defined for CSS, based on the order in
> which you reference them in the HTML? Maybe that's the best way to
> separate between the shared CSS and the user-specific CSS.
>
> Maybe this doesn't make as much sense, since we're only talking about
> the calendar colors here. But if possible, I think it would be better
> for CSS stuff to not be generated at runtime.
>
> Anyway, those are the thoughts I had on the issue.
>
> Later,
> --
> Wesley Miaw
> we...@we...