How to make application more easily skinnable?

answered 2010-05-06 15:51:41 -0500

Pekka
550 ● 22 ● 28 ● 37

how should site administrator change/customize skin?

I think the current way skins are customized is fine. The template system is easy to understand, and Django's cascading mechanism (i.e. if a file isn't there in the custom template, load it from the default directory) is great. I personally am also fine with the skin being defined in a config file. Once there's an admin tool, it's of course also nice to have it there as a drop-down menu, but it's not really a priority IMO.

what naming conventions to choose for id and class names

I think it pretty much doesn't matter as long as they are consistent, and written down in the Wiki.

I would propose to make a choice between Camel Case and underlines:

.MainQuestion or .main_question

there are arguments for and against both of them. Using underlines and small caps prevents case errors that are often easy to overlook.

Other than that, I think class names should be as short as possible, and be defined by function (and not by properties).

.YellowBox No! .InfoBox yes!

One thing that should be decided early on is whether we're going to use multiple classes. Using more than two classes breaks in IE6.

Multiple classes would be a great tool. Consider

    <div class="InfoBox LeftMenu Warning">

it would be possible to split CSS rules that generally apply to Info boxes, rules that apply to Info boxes in the left hand menu, and Info boxes that are warnings into three reusable classes.

We are going to want to support IE6 in the standard template, though, I presume. Sadly, it still has a considerable market share.

what elements to pick as "application native" and which - leave them as part of local customization?

Can you make an example of an element that could be part of the local customization? I'm not sure I understand this entirely.

how to make javascript that is part of UI automatically work in new skins?

This is a very good question. If I understand Django's templating system right, it would be possible to have a common.js in the default template. As long as people don't overwrite that with a local common.js in their template, the default file is used. Is this correct? If it is, I would suggest to maintain a core JavaScript directory that is directly connected with the JavaScript framework used.

/default/media/js/askbot_core/jquery.js
/default/media/js/askbot_core/org.askbot.editor.js
/default/media/js/askbot_core/org.askbot.utils.js
/default/media/js/askbot_core/...

people looking to customize their template will be told not to create a askbot_core directory so the one from the default template can be used (and updated). Should people, however, want to fork the JavaScript core (e.g. in order to use a different JS framework) they can override the askbot_core directory completely (at their own risk).

Would this be a workable idea? I'm still a total newbie in all matters Django and Python.

One other thing we should be working on is using semantically correct elements everywhere. There are a few page titles here and there that are divs that really should be h1, h2 etc...