Currently there is no proper way in Lua to get such basic things about the current page name. To fix this, I propose to provide a MediaWiki API accessible from the Lua scripts: https://www.mediawiki.org/wiki/Extension:Scribunto/API_specification Any feedback appreciated.
— Victor.
* Victor Vasiliev vasilvv@gmail.com [Sat, 2 Jun 2012 22:43:56 +0200]:
Currently there is no proper way in Lua to get such basic things about the current page name. To fix this, I propose to provide a MediaWiki API accessible from the Lua scripts:
https://www.mediawiki.org/wiki/Extension:Scribunto/API_specification
Any feedback appreciated.
— Victor.
Is that local PHP bindings only or the remote MW API querying will be possible? In MediaWiki, API usually means "do something remotely", although local API usage is possible (except for very hard parts where POST is required - but maybe that was fixed in recent versions of Request / Response abstractions). I am asking because when there are two different things called "API" this may cause some confusion. Dmitriy
On Sat, Jun 2, 2012 at 1:43 PM, Victor Vasiliev vasilvv@gmail.com wrote:
Any feedback appreciated.
(Caveat: I'm new to Mediawiki development and have only a shallow understanding of its internals.)
I find getSomething syntax to be cluttered and verbose. The "get", the mixed case, the function invocation -- these things are not encoding useful information, so they exist as a kind of syntactic line noise. I find it much easier to orient myself around APIs that make use of property accessors -- obj.foo rather than obj.getFoo().
It looks like they are doable (and performant) in Lua: < http://nova-fusion.com/2011/04/04/implementing-proper-gettersetters-in-lua/
.
It's possible to go too far with properties*, though, so I make an exception for data points that are expensive to look up. In such cases the get and the invocation _are_ encoding useful information: i.e., the fact that the information isn't available on hand and needs to be fetched. But more often the fact that some value need to be computed is an implementation detail that your users shouldn't have to care about.
My second quibble is with the mw.title interface. Most of the other interfaces follow a loose convention of mw.object.getPropertyOfObject(), but mw.title.parse(text) seems to get things backwards -- it's mw.property.getFromObject(), if you will. I find that a bit confusing.
In general, I'd prefer it if there was a sharper distinction between the REST-like resources-with-methods semantics (mw.page, mw.site) and the "standard library" approach whereby things are bundled according to functionality (mw.time, mw.url).
Hope this is useful. I think it's a cool project.
Ori
* I've made this mistake before: <http://djangosnippets.org/snippets/2582/
.
On Mon, Jun 4, 2012 at 12:30 PM, Ori Livneh ori.livneh@gmail.com wrote:
I find getSomething syntax to be cluttered and verbose. The "get", the mixed case, the function invocation -- these things are not encoding useful information, so they exist as a kind of syntactic line noise. I find it much easier to orient myself around APIs that make use of property accessors -- obj.foo rather than obj.getFoo().
Done. I've updated spec with properties
My second quibble is with the mw.title interface. Most of the other interfaces follow a loose convention of mw.object.getPropertyOfObject(), but mw.title.parse(text) seems to get things backwards -- it's mw.property.getFromObject(), if you will. I find that a bit confusing.
I'm not sure I quite get this one.
In general, I'd prefer it if there was a sharper distinction between the REST-like resources-with-methods semantics (mw.page, mw.site) and the "standard library" approach whereby things are bundled according to functionality (mw.time, mw.url).
Well, they are all bundled according the functionality (get current page info, get site info, i18n functions, etc.).
Hope this is useful. I think it's a cool project.
Thanks!
— Victor.
wikitech-l@lists.wikimedia.org