Your idea on widgets is actually a bit similar to something I was thinking about earlier on today.
There are a lot of extensions which do similar things. And a lot of things which have a lot of variance to them. Then there is a fair bit of variance to how certain things are done and handled with extensions. Honestly, some of this makes the idea of a 'Extension Installer' that people propose to be a little tough.
For example, variables are used allot in extension files. However, most of the time none of these are globalized. As a result of this, it is impossible to delegate the inclusion of an extension to a special function made to simplify the task. So, instead we make the one installing the wiki use a cryptic require_once statement. And delegate everything being done to the extension itself forcing it to handle everything. I did entertain the idea in my own time of using: include extension('CheckUser'); ^_^ Of course, that's a little bit of a visual hack I came up with. 'extension' would be an actual function. Designed with the task of outputting a string for inclusion of an extension. Nonexistant extensions and such would be handled by a die statement inside of it... Or even better, I could let a configuration option make the function silently pass nonexistant extensions over by passing the name of an empty but existing file and write out to the debug logs that the extension could not be loaded. ;) If you get the thought, it would mean that accidentally removing the files for an extension wouldn't crash your site, it would just silently work without the extension.
But, that's just a little tangent thought. And it's extremely limited, like how it is limited to only a file, and is required to output that file even if it can't fine one.
My thought was a refactoring on how extensions are actually done. Rather than making extensions a tangent thought where we give them a bunch of hooks they can subscribe to, and beyond that do extremely little to interact with them and simplify how much the extensions actually need to do on their own.
I thought of actually integrating the notion of an 'extension' into core a lot more. One of the ideas was an Extension class. - An extension subclasses the Extension class with it's own class to identify itself. - Because classes are outside of the scope limitations, we can delegate inclusion of files to anywhere, including functions which are easier for users to understand. - We can have the extension store it's configuration options inside of it's own object. -- This makes sure nothing can ever collide with other extension variables or core variables. -- The Extension's class can pass itself into any class that it creates. And as a result let them access the configuration options to use. - The core Extension class would be preloaded with a number of useful methods for extensions to use.
While we're at it, there was something that I discussed with TimStarling. Rather than using wfLoadExtensionMessages, and being forced to load every single one of them when we need to find a single message for a MediaWiki: page. There is another potential way to get messages which does not require us to load everything and reduce performance. A lot of extensions use prefixes. And that is a real fair bit of them. Nearly every one in SVN has it's own unique way to start the names of it's own messages unless it's using a basic word. There is potential for an extension to register a message prefix with the system. And then, when MediaWiki needs to find a message, instead of loading all the messages for every extension it would check the name of the message for a registered prefix, and load the messages for the extension if needed. Tim even tells me of some sort of text tree I think it was, which would suit this better than iterating over and entire array to search for a prefix.
As for identification of the extension itself. We could put that kind of data into a method in the extension's class, and instead of using a global set every load, and unreliable if extensions don't identify themselves. We could even list on Special:Version "X unidentified extensions installed."
And, we can even reduce how much is loaded. A lot of extensions repeat functionality of certain things. One type of thing for example is pure Parser Function extensions. Ones made purely to create a new ParserFunction. We could do a number of things with this kind of extension. Firstly, we could subclass the Extension class and preload important types of configuration which these extensions would normally do on their own. Meaning that the actual work needed for extensions this simple would be reduced. And there's something even better. When do we even need parser functions? We need them in the Parser, we need them in the parser, we list them on Special:Version... But honestly, we don't need to load them every page view. And that's what a lot of extensions using the body file tactic do. In fact... We go and register ParserFunctions by making a call to $wgParser for each and every one of them. What if all the things on the page which needed to be parsed were actually already in the cache? We'd have to go and unstub the Parser class just to register a number of parser functions which aren't going to be used. And honestly, while there are still a few messages which are parsed for each page load, it would be quite possible to cache those with the page title and make it so that at some times when viewing MediaWiki you don't need the parser to ever be unstubed. This could be said for a fair number of different things. Why load everything, when only one of those things is needed? So we could potentially group out different things that extensions may add and have the extension setup callbacks of things to load. And so we'll only load various parts of the extension if they are actually needed.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Sergey Chernyshev wrote:
Dan,
I think it's perfectly fine to create this documentation within MediaWiki.org - there is no need for special features on the site, just documentation, right? It seems to be a natural place to search for such information.
As for code generator, I think it's an overkill to start with such complex thing - getting just boilerplates is a good short first step which will benefit generator once code stabilizes. Moreover, code can be included right into wiki pages instead of SVN to minimize learning curve because people who use SVN are already less prone to coding mistakes then people who just copy/paste and those are the most important people to target.
I also created Widgets extension partially to help eliminate those extensions that just print out some HTML based on the input without employing much of the logic - they all can be replaced with templateing language instead (Widgets uses Smarty). I already converted my SlideShare extension to SlideShare widget to start with.
I'll be happy to be a user of such documentation and best practices documents and help "debug" them ;)
SergeyOn Fri, May 9, 2008 at 3:15 PM, DanTMan dan_the_man@telus.net wrote:
Unfortunately there really isn't good documentation on creating extensions for MediaWiki. And a lot of the existing documentation is badly out of date. (This is kind of the reason why we still see a lot of use of the SpecialPage::addPage method when it has been depreciated).
Actually, JaeSharp once poked me to help start on creating a good source of help. I've got SMW and a good setup, cept I need to get God to watch PHP to keep it alive. I could create a developer help wiki for MediaWiki.
^_^ As for the boilerplate code... Honestly, JaeSharp was planning on creating a kind of generator code... Like how rails has generators to create scaffolding (models, views, and controllers which already work out of the box). That way extension developers could simply run a script with the name of their extension, and a bit of input on what kind of things they are using... Do they want it to not output i18n files, any special pages to create, any parserfunctions that need a i18n.magic, or extension class. And create relevant files from that.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Sergey Chernyshev wrote:
Dan, thanks for this long overview, is there a wiki page on MediaWiki.org that describes all this? If not, I'll just refactor your email to a page
if
you don't mind.
It probably also makes sense to maintain some boilerplate code as well so new developers can have an easy start.
Sergey
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l