This is a MediaWiki code design discussion; people uninterested in
MediaWiki's guts can safely ignore it.
So, I think one of the big questions third-party admins have is how to
skin MediaWiki. Right now, it requires writing some PHP code. I'd like
to float some suggestions for how we can make our skin architecture a
bit easier for everyone.
In MediaWiki 1.5, I think we should re-focus our Skin classes
specifically on *HTML generation*. I think we should keep the name
"Skin", just because it's hard not to, but I think we should steer away
from using server-side PHP code to do layout design.
Instead of having skin classes for them, I think we should use alternate
CSS stylesheets to provide the "look-and-feel" differences -- Monobook,
Nostalgia, Standard, and Cologne Blue, as well as future look-and-feels.
Hopefully, if we can make this transition, we can open up the process of
skinning MediaWiki to people with more CSS/(X)HTML experience than PHP
chops, and get more/better-looking/easier-to-use skins. Admins who want
to have "branded" styles for their sites could do so with CSS.
To support browsers that can't handle CSS styling (I think lynx is the
only one in wide usage that is in this category, but there may be
others), we should provide another HTML generation class on the server
to make very simple, style-free HTML.
Extensions -- hopefully third-party extensions -- could provide HTML
generation from PHP template systems like PHPTal, Smarty, etc. *I*
wouldn't use them, but for folks who are really into these templating
system, there'd be an option. There may also be call for a skin subclass
to generate table-based layout for HTML 3.0-era browsers.
Lastly, I think we should push most of the business logic of skins up to
the root class. By this I mean stuff like: figuring out whether or not
to show admin function links, or links that should only be shown for
articles, or links that should only be shown for logged-in users, or
whatever.
Historically this has been replicated in each skin class, but in recent
versions there's been some consolidation. It would be great to finish
this process and get all this code into one spot in the root skin class.
I think the PHPTal/SkinTemplate mechanism -- one function per logical
"menu" (nav urls, personal urls, etc.) returning an array of arrays,
each one representing a link -- is the best system here.
Attached is a rough class diagram to illustrate these ideas. To
summarize:
* Abstract class "Skin" provides a framework and supports business
logic for determining which links are shown, etc.
* SkinBasic gives rock-bottom, dead-simple HTML.
* SkinTemplate is the most-used, default HTML generator. It allows
an alternation between multiple CSS stylesheets, and generates
the kind of high-quality HTML (or XHTML if the browser is
capable) to make CSS-styling simple and useful.
* SkinPHPTal and SkinSmarty are third-party HTML-generation
classes that use those templating systems. There could be other
such classes; they're only on the diagram to illustrate that we
want skins to be able to handle this kind of subclassing.
Now, we're awful close to something like this already; I think the
SkinTemplate class in 1.4, with some changes for handling multiple
alternate CSS stylesheets, is a really good "default" class. Although
it's not a requirement, the other HTML generators could use the same
stylesheets as long as they generate similar HTML.
The main drawbacks with this kind of system are:
1. We won't have pixel-identical versions of Nostalgia, Standard,
and Cologne Blue. I don't think this is a huge problem.
2. Folk wisdom that "Nostalgia makes HTML that can be read in lynx"
would become untrue.
3. We have a couple of classes that vary by the user's preferences
(SkinBasic versus SkinTemplate), and a couple that vary by the
sysadmin's preferences (SkinTemplate vs. PHPTal, Smarty, ...).
4. It's not clear how to allow different stylesheets. There's a
good way here:
http://www.alistapart.com/articles/alternate/
I realize we're in a release cycle and 1.5-timeframe discussions are
somewhat distracting, but I've been thinking about this and figured it
was worth discussing while I still had it in my brain.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>