Hi, Is there a technical documentation/blogs/articles of mediaWiki available on net. I went through this link http://www.mediawiki.org/wiki/Category:MediaWiki_technical_documentation, but I am looking for more of architecture of mediaWiki , specifically that talks about Using Jquery and Sajax in media wiki .
Thanks
2010/3/15 Sanyam goyal goyalsanyam@gmail.com:
Hi, Is there a technical documentation/blogs/articles of mediaWiki available on net. I went through this link http://www.mediawiki.org/wiki/Category:MediaWiki_technical_documentation, but I am looking for more of architecture of mediaWiki , specifically that talks about Using Jquery and Sajax in media wiki .
sajax is the 'old' way of doing AJAX in MW and is discouraged. The use of jQuery isn't really documented very well right now, as most of the standards are still under development. Basically you can just use $j as an alias for jQuery and try to copy the style from existing extensions using jQuery, like UsabilityInitiative and LiquidThreads.
Roan Kattouw (Catrope)
* Roan Kattouw roan.kattouw@gmail.com [Mon, 15 Mar 2010 20:17:06 +0100]:
sajax is the 'old' way of doing AJAX in MW and is discouraged. The use of jQuery isn't really documented very well right now, as most of the standards are still under development. Basically you can just use $j as an alias for jQuery and try to copy the style from existing extensions using jQuery, like UsabilityInitiative and LiquidThreads.
Why sajax is discouraged to use? I hope that it won't be dropped, because it's small and has very little setup overhead. CategoryTree and my own extension uses it. Will v1.16 release include jQuery? 1.15 has a lot of installations, too. Can't there be sajax to jQuery compatibility layer (implementing sajax functions "indirectly" via jQuery)? Dmitriy
2010/3/16 Dmitriy Sintsov questpc@rambler.ru:
Why sajax is discouraged to use?
Basically because using jQuery on the frontend and API modules on the backend is much cleaner, so that's what we recommend for use in newly written code.
I hope that it won't be dropped, because it's small and has very little setup overhead. CategoryTree and my own extension uses it.
Yes, there's some stuff built on sajax, that's a known fact so it won't just be killed.
Will v1.16 release include jQuery?
Yes, although the way jQuery is included will probably change in 1.17 with the (planned) introduction of a script loader.
1.15 has a lot of installations, too. Can't there be sajax to jQuery compatibility layer (implementing sajax functions "indirectly" via jQuery)?
How is that relevant to 1.15 installs being around? Extensions have different versions matching different versions of MediaWiki, so this shouldn't be a problem at all. Like I said, sajax will be kept around for some time to come, and if your extension uses jQuery it shouldn't be claiming compatibility with 1.15 and below.
Roan Kattouw (Catrope)
* Roan Kattouw roan.kattouw@gmail.com [Tue, 16 Mar 2010 11:38:11 +0100]:
Will v1.16 release include jQuery?
Yes, although the way jQuery is included will probably change in 1.17 with the (planned) introduction of a script loader.
Let's hope that won't alter much the actual usage of it.
1.15 has a lot of installations, too. Can't there be sajax to jQuery
compatibility
layer (implementing sajax functions "indirectly" via jQuery)?
How is that relevant to 1.15 installs being around? Extensions have different versions matching different versions of MediaWiki, so this shouldn't be a problem at all. Like I said, sajax will be kept around for some time to come, and if your extension uses jQuery it shouldn't be claiming compatibility with 1.15 and below.
Sometimes newer versions of extensions have important fixes, but unfortunately these extensions versions may be incompatible with older versions of MediaWiki, at the same time. It probably will be harder to backport. Ok, nevermind. Dmitriy
Dmitriy Sintsov wrote:
Sometimes newer versions of extensions have important fixes, but unfortunately these extensions versions may be incompatible with older versions of MediaWiki, at the same time. It probably will be harder to backport. Ok, nevermind. Dmitriy
So you also update mediawiki?
* Platonides Platonides@gmail.com [Wed, 17 Mar 2010 15:40:40 +0100]:
Dmitriy Sintsov wrote:
Sometimes newer versions of extensions have important fixes, but unfortunately these extensions versions may be incompatible with
older
versions of MediaWiki, at the same time. It probably will be harder
to
backport. Ok, nevermind. Dmitriy
So you also update mediawiki?
Sure, I do. However, the old core was privately patched, so custom patches has to be ported to new core. Also, newer versions of extensions sometimes work with new core, sometimes they don't. Sorry, I've probably asked too much. Dmitriy
Dmitriy Sintsov wrote:
Sure, I do. However, the old core was privately patched, so custom patches has to be ported to new core. Also, newer versions of extensions sometimes work with new core, sometimes they don't. Sorry, I've probably asked too much. Dmitriy
The core patches should be moved into hooks, so you don't have to patch the same thing every time.
* Platonides Platonides@gmail.com [Wed, 17 Mar 2010 18:43:38 +0100]:
The core patches should be moved into hooks, so you don't have to
patch
the same thing every time.
Unfortunately, not every hack is possible to implement via the hook. For example, user groups are weak, there is no Group class or at least a good group management in User: CMS needs that. One should introduce new hooks, but you have to convince lead developers that your hook is really worth to be included into the core. Some hacks probably should be done via the class extensions (by replacing them in Autoloader), I've heard that PHP 5.3.x allows to dynamically add new methods: http://blog.agilephp.com/2009/03/31/real-programming-with-php-53-part-2-java... I know that Parser already nicely allows to use extended class via the $wgParserConf['class'], but some other classes aren't so easy to extend. But, I am not sure that extension of classes would not break on core upgrade . Dmitriy
wikitech-l@lists.wikimedia.org