On Tue, Mar 20, 2012 at 7:45 PM, Platonides <platonides(a)gmail.com> wrote:
"Documentation designed for libary developers,
useless for developers
using the library" isn't a good slogan either :)
Touche. ;) I'm probably going to start the end user documentation
on-wiki, starting at [[User:Madman/Dementia]] which may move into
project space at some point; I hope those interested in the framework
will contribute. :)
I expected something like that.
How are you doing the db backend? Are you loading MediaWiki and using a
FauxRequest?
Yep. Obviously, there are some limitations to this approach; for
example, DementiaRequest falls back to the HttpBackend when an edit
token's requested as there's no way for it to get session data and
edit tokens aren't based on database information. I hope to mitigate
some of these limitations in time, with caching and the like, but if
the worst case is using HTTP, which would have been used anyway... eh.
I just hope all the cases where DbBackend will be useful aren't edge
cases.
This does necessitate having a working copy of MediaWiki, which has to
be patched in two places (a script does this automatically) so it
doesn't attempt to expire blocks (which it would attempt to do even
when $wgReadOnly is set) and so the option to force a given index is
ignored (because the Toolserver doesn't have some-- maybe most-- of
those indexes). In the long run, I hope to strip the files that need
to be checked out to the bare essentials and I'm always open to better
suggestions (including "wtf were you thinking? Using <x> is ten times
as obvious"). I frequently miss the obvious.
Well, I'd expect a handful of examples from which
the pattern would b
easy to infer, plus some explanation for when you need to use a new
module for which there's no example.
Will do. :) I'll probably use each of the API's examples and show how
to execute the request via the framework and explain which backend it
would use. (I run unit tests against each of the API's examples
anyhow.)
The point at
the moment is that the framework automagically handles
all prefixing of parameters, including generators' parameters, so the
end user's code is more readable; it also continues queries
automatically and selects an appropriate backend for actions and
queries (which is its primary purpose).
It even does more than I expected.
Also the benefit I forgot is never having to write SQL queries for
common queries (categorymembers and the like) since the backend knows
how to do that.
My point is, if I wanted to perform an api query which
I had. I have no
idea how to do that with your library.
When should the parameters be prefixed and when not, for instance.
NEVAR. :p
Not to mention if I wanted to translate a more complex
query with a
generator, such as:
https://commons.wikimedia.org/w/api.php?action=query&generator=search&a…
In case you're curious:
$search = DementiaQuery::factory('search');
$search->setSearch('"chartres cathedral"')->setNamespace(6);
$search->setOffset(20)->setLimit(20);
$imageinfo = DementiaQuery::factory('imageinfo');
$imageinfo->setProp('url');
$imageinfo->generator = $search; // just to show both ways of setting parameters
while ($pages = $imageinfo->execute()) {} // this will loop,
continuing the query automatically until no more results are available
Unfortunately this too would use the HttpBackend as the Toolserver
doesn't have the searchindex table. But I do like the syntax.
Madman