On Wed, 01 Feb 2012 04:04:50 -0800, Roan Kattouw &lt;roan.kattouw(a)gmail.com&gt; wrote: I haven't been able to release the skinning tutorial I've been working on, but I have a new recommended file layout for non-core skins. Goes something like this, assuming a skin called "CloneBook": clonebook/clonebook.php clonebook/CloneBook.i18n.php (or maybe clonebook/clonebook.i18n.php?) clonebook/CloneBook.skin.php clonebook/*.{js,css,etc...} (or something like clonebook/styles/*.css or clonebook/css/*.css if you feel like it instead) You put the $wgValidSkinNames, $wgAutoloadClasses, $wgResourceModules, etc... data inside of the clonebook/clonebook.php file and include it like an extension: require_once("$IP/skins/clonebook/clonebook.php"); This gives you a number of advantages: - You can finally throw your skin into a tarball and distribute it in a way that can simply be extracted - You don't lose the advantage of resources sitting inside of skins/ - You have a good place to define things like resource loader modules - You have a place for i18n, which was sort of missing before - You can also define extension credits for your skin and get attribution The key reason for putting it inside of skins/ instead of extensions/ is that by putting it inside of skins/ we have the advantage of having a absolute fact saying that "This is a skin", not some complex extension. And that means that we can start making conventions that are based on that fact and start stripping away the requirements to use extension-like code by slowly introducing various bits of auto-loading into future versions of MediaWiki. For example in a future version of MediaWiki we may suggest replacing require_once calls and have some sort of skin manifest: SkinLoader::registerSkin( 'clonebook' ); clonebook/clonebook.skin.xml <skin> <key>CloneBook</key> <name lang="en">Clone Book</name> <description lang="en">A clone of MonoBook... what else do you need?</description> <author url="//mediawiki.org/wiki/User:Dantman">Daniel Friesen</author> <mwpage>Skin:CloneBook</mwpage><!-- Alternative to url --> <resource-module> <style media="screen">screen.css</style> <style media="print">print.css</style> </resource-module> </skin> Then you would have your conventional clonebook/<key>.skin.php file and $wgValidSkinNames, $wgAutoLoadClasses, and wgResourceModules would all be implicitly set, your extension credits would be implicitly set, and the name and description of the skin would implicitly be put into i18n. You would only need an i18n file at that point if you actually used custom i18n message keys inside of your skin. Not just to i18n the name of your skin and it's credits description. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 12-02-01 5:11 AM, Sumana Harihareswara wrote: I've always had very little spare time to code or do anything substantial, especially with writing. And my employer wanted to get a little publicity out so we could get more clients who wanted us to do MediaWiki Skinning work (Really, being stuck in WordPress is HELL). So I decided to convince my employer to let me spend work hours writing the skinning tutorial and publish it first on a new company blog before putting an editable derivative up in the manual. And unfortunately we've been too busy and chaotic (I got sick) to move on with it. So unfinished or finished I can't hand it out without an ok since I don't have the implicit copyright given I used work hours (and I used what added up to at least a weeks worth of work) to write it. I sent a message to Greg on the topic. Though he's been busy lately and one of our clients with an upcoming Oprah appearance has been hammering him with calls, even off-hours. No one sent me any information about that -- In fact this might be the first I've even heard of it. Though I'd love to see their ideas. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Feb 3, 2012, at 7:33 PM, Daniel Friesen wrote: I haven't had time to respond to this, I've been a bit swamped… Here's a summary... The approach we took was to make a self contained and modular mini-framework for building skins. It borrows a lot from Symfony. Typically with mediawiki skins, you have a giant skin template file which defines an template object and contains bunch of html, which then calls a bunch of helper functions to build more html. We felt it got pretty unmanageable pretty quickly with our Monaco skin, which takes the same approach. What we did with Oasis was basically reduce it to this: class OasisTemplate extends QuickTemplate { echo Module::get('Oasis', 'Index')->render(); // or echo wfRenderModule('Oasis', 'Index'); } And then define a Data TransferObject + Controller hybrid. All public variables are exported to the template, which reduces the amount of boilerplate PHP syntax to a minimum: class OasisModule extends Module { public $foo; public $bar; public $wgGlobalVar; // any global reference is auto-copied to the template public function executeIndex() { // any function called executeX is "dispatchable", the rest are helpers // controller logic goes here $this->foo = FooService::getSomeFoo(); $this->bar = BarService::getSomeBar(); } } And the template/view is just a raw php file called Oasis_Index.php : <div> <div> <?php if (isset($wgGlobalVar)) echo $foo ?> </div> <div> <?= $bar ?> </div> <div> <?= Module::get('Something', 'Index')->render(); ?> <div> <?= wfRenderModule('OtherThing', 'Whatever'); ?> </div> As long as the names match up, the Module class matches up the controller method and the view template (Index, in this case). Of course, when we got to really building the skin, it got a lot more complicated, and now it's undergone a bit of a transformation into a more formal MVVC framework which obscures the simplicity of the original approach. But that was the idea. We have something like 40+ modules in the skin itself, and who knows how many more in extensions. The nice thing about this was that doing Module::get("Thing", "Index")->getData() will just give you a raw array of data, which means any controller methods can double as an ajax call (after transforming it to json) or a service class for some other piece of PHP, which is a shortcut we use a lot. At this point, the Oasis skin has been stretched (ha) far beyond it's initial design and it's holding up… okay, I guess. It's easy for people to find one small section of the code and just work on that, and you can test individual components separately and see the raw data or the raw html for any module directly in the browser, which was the goal. The modules actually got converted to something more like full blown controllers with a dispatcher framework a while ago. You can see the current version of the entry point here: http://trac.wikia-code.com/browser/wikia/trunk/skins/Oasis.php And an example of how the modules can get pretty complex, and how you DON'T want that logic in a template: http://trac.wikia-code.com/browser/wikia/trunk/skins/oasis/modules/LatestAc… http://trac.wikia-code.com/browser/wikia/trunk/skins/oasis/modules/template… and an example of the raw data for that exact bit of code on a live wiki: http://community.wikia.com/wikia.php?controller=LatestActivity&method=I… and the html without the rest of the skin: http://community.wikia.com/wikia.php?controller=LatestActivity&method=I… It's really not MUCH more complicated, and I think the basic concept could be extracted and simplified and open sourced pretty easily. Oasis at this point depends on a LOT of other wikia code, but the design itself doesn't. And it's all one step closer to a more formal web services framework, which is I guess where we are going in the long run…? I'm not sure if this is something anybody else is interested in, but I'm happy to provide more details. owen(a)wikia-inc.com