On 11-09-11 04:56 PM, Rob Lanphier wrote:
On Thu, Sep 8, 2011 at 11:04 AM, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
Aye, there's absolutely no way HAML is going
to fly with the majority of
people building skins.
Instead of "Why the hell do I have to insert all this junk just to make
my skin work right? I'm going back to WordPress." kind of issue we had
before I cleaned up the skin system we'll end up with a "What the hell
is this syntax? I'm going back to Drupal." kind of issue.
I'm curious
what problem you're trying to solve. It sounds like
you're trying to get people who are currently working on Wordpress
skins or Drupal skins to work on MediaWiki skins instead, but to what
end?
Rob
The "going back to <x>" part tacked on the end was more of a
joke.
I'm trying to solve the flaws in our skin system especially the ones
where our skin system is deficient compared to other theme engines like
WordPress' and Drupal's. But also trying to avoid repeating some of the
same flaws in those skin systems. And taking our differences into
consideration.
Basically trying to make the skin system compact yet flexible enough for
someone to build whatever skin they're trying to make, but without piles
of unnecessary boilerplate, issues with new features disappearing,
deficiencies in the skin system making something simple impossible
without implementing a bunch of functional level code like navigation
parsing into the skin itself.
Part of the plan is a new template based system:
- In a template system we can eliminate the <?php echo,
htmlspecialchars, $this->, and other pieces of unnecessary boilerplate
that builds up in a skin. (Rather than `<?php /*...*/
$this->data['nav_urls']['mainpage']['href']/* ... */ ?>`,
`{nav.mainpage}`)
- With context sensitivity and new template keys that understand more
about the data we can eliminate excessively long boilerplate needed to
insert a simple piece of text in a safe way (and make it easier to do
things safely than to accidentally introduce an xss vector).
- With a template the skin system can also understand what is used in
the template and alter the output as relevant to make older skins work
with new features. (eg: If we introduced a page-icons feature into core
and added a new key to insert that where it best fits in a skin we would
have an issue where slightly older skins didn't have it and when someone
installed and used them a core feature wouldn't function. But in a
template based system it's possible for the skin system to look at the
template, note that a location for pageicons is not defined, and output
the pageicons into the title to put it in a common location.)
Implicitly the plan also involves ditching the plain precomputed key =>
value pattern we have. This pattern is the reason for other limitations,
like issues with having separate types of nav other than the sidebar
without having to parse each and every one of them, even when not used,
and having to extend skin calls with $this->getSkin().
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]