* Daniel Friesen lists@nadir-seen-fire.com [Mon, 12 Sep 2011 02:48:35 -0700]:
On 11-09-11 04:56 PM, Rob Lanphier wrote:
On Thu, Sep 8, 2011 at 11:04 AM, Daniel Friesen lists@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().
The most interesting thing I've heard about skin language was XSL with C-like syntax, mentioned by Gregory Maxwell some years ago in this list. I don't remember the link, maybe that one? http://fdik.org/yml/yslt http://www.xm.co.nz/ShoXS.htm Dmitriy