* Daniel Friesen <[email protected]> [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 > > <[email protected]> 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
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
