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().
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]