I've done a little more thinking about this and I've take a look at Blojsom (Java) and Serendipity (PHP), which was suggested by Sean Gilligan. I didn't see anything of interest in Blojsom, but Serendipity had a couple of nice ideas.
First of all, they provide a default theme CSS file, which includes all CSS classes generated by the system and includes comments that explain the purpose of each class. I'm planning on doing this for Roller next week. Default theme stylesheet commented http://www.s9y.org/122.html For templates, Serendipity uses the Smarty template engine and they put a bunch of variables into context, no surprises here. Smarty http://smarty.php.net/ CSS classes / Variable Documentation http://www.s9y.org/102.html They also allow the configuration of theme options, which is very similar to the theme properties approach I am proposing -- except they don't have a property definition fine that defines the types and allowed values necessary to present a slick config UI. Configuration of Theme options http://www.s9y.org/137.html And to respond to Allen's last email on the topic... On 12/5/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I am glad to hear that there is already a Widgets proposal on the way because I am far more interested in seeing us accomplish that. But about the theme properties again, you said twice below that you think it's a good thing that theme authors get to decide what properties are configurable and that they don't have to provide properties if they don't want to, but I don't fully agree with that. To me the point of this proposal is to provide some way of ensuring that the themes people will develop for Roller in the future will be user friendly such that they can be customized to some degree without having to edit their templates directly.
I disagree with that. We need to keep theme creation simple and no put an undue burden on theme developers who just want to throw together a simple theme with no configurable parts. The point of the proposal is to put in place a system that can enables the creation of customizable themes that can be customized very easily with a nice web UI with "pickers" for colors, fonts and images. Theme authors can choose to use this system or not. The themes that provide the best appearance and appropriate level of configurability will win out. A big site like blogs.sun.com could choose to develop a family of themes that all use the same CSS classes and for consistency the same configuration properties. But other sites could choose to build themes that use a different set of properties. We can't imagine all the ways that theme authors might want to make their themes configurable, so we shouldn't mandate configurabilty.
IMO there is no real incentive to get theme developers to develop these theme properties into their themes and if they aren't doing it then we have gained almost nothing. I will agree that theme properties do solve the technical problem of how to maintain some configurable data to be used in a theme, but it does not really encourage themes to be easily built for configurability.
No. We will have gained "system that can enables the creation of customizable themes that can be customized..." -- that is not nothing. And the cool configuration UI will most definitely encourage theme authors to expose configuration properties. All they have to do is define a couple of properties in an XML file and then use them in the theme.
Another reason why I am still very hesitant to do theme properties is that once we introduce this feature there is no turning back. We will likely never have a way to go back and remove this feature if we decide it didn't work out as well as we wanted because peoples themes will be reliant on the properties. So I want to make absolutely sure that this is the very best way to solve this problem before we introduce it, and so far I am not convinced.
That's going to be true of pretty much any solution to this problem. With APIs, page models and macros we need to step very carefully as you suggest.
I believe there are alternatives out there that we may not have considered yet which will solve this in a more robust way.
The only one we've discussed thus far is Sidebar Widgets, which combined with theme properties solve the problem IMHO but alone they don't come close. Have you come up with any other alternatives since we last corresponded? - Dave
