On Tue, Mar 20, 2012 at 7:45 PM, Platonides <[email protected]> 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&gsrnamespace=6&gsrsearch=%22chartres+cathedral%22&gsrlimit=20&gsroffset=20&prop=imageinfo&iiprop=url 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 _______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
