https://bugzilla.wikimedia.org/show_bug.cgi?id=17784
--- Comment #2 from David Tabachnikov <[email protected]> 2009-03-05 17:38:43 UTC --- (In reply to comment #1) The patch I submitted was a refactored version of a custom API call I made for our special use case. Some of the problems you talk about come from that. Sorry for that, I shuold've checked it more throuhgly before submitting. > >+ private $prefix, $module, $description; > All three of these are superfluous: $description isn't even used, $prefix is > only used once in the constructor and can be eliminated easily, and every > usage > of $this->module should be replaced by $this->getModuleName(). > Removed $module and $description, but left $prefix, so our custom API call could override it. > >+ private function returnCount($res) { > >+ $data = array("count" => $res); > >+ > >+ $result = $this->getResult(); > >+ $result->setIndexedTagName($data, 'count'); > >+ $result->addValue('query', $this->getModuleName(), $data); > > > >+ } > This looks horribly broken; if I understand correctly, this'll try to put an > object in the result, which leads to nasty errors and is not what you want. > You > probably want something like intval($res->getCount()) (dunno how SMW's result > objects work exactly), in which case you also don't need the > setIndexedTagName() call because $data doesn't have numerical indices. > Actually, I checked that, and what happens, is that when the Semantic MediaWiki processor runs in "count" mode, the resutl of getQueryResult is an string with the result of the count, not a SMWQueryResult object. Might be broken - but it's broken inside SMW. > >+ $data[] = array( > >+ 'pageid' => > >intval($object->getArticleID()), > >+ 'ns' => > >intval($title->getNamespace()), > >+ 'title' => > >$title->getPrefixedText()); > >... > >+ $result->addValue('query', $this->getModuleName(), > >$data); > Since a recent breaking change in the API (r46845), your code should be > prepared to handle the case in which $data doesn't fit into the result object, > in which case addValue() will return false. This means you have to add the > results one by one and check addValue()'s return value, like this: > > $vals = array( > 'pageid' => intval($object->getArticleID()), > 'ns' => intval($title->getNamespace()), > 'title' => $title->getPrefixedText()); > $fit = $result->addValue(array('query', $this->getModuleName()), null, $vals); > if(!$fit) { set a query-continue and break out of the loop } > ... > // And after the loop: > $result->setIndexedTagName_internal(array('query', $this->getModuleName()), > 'page'); > > Note that this code only works with MediaWiki 1.15alpha; 1.14 and earlier > versions don't have the setIndexedTagName_internal() method. > I need this code to work in 1.14 and eaerlier (we currently use 1.13.5). I'd really appreciate any points on how to properly write it so it will work in both 1.13 and 1.15? It could be really great if you could give me some pointers as to how to do this properly. > >+ private function parseQuery($query) { > >+ global $wgParser; > >+ > >+ // Initialize the parser options > >+ $options = new ParserOptions(); > >+ > >+ // Preprocess the query, before running > >+ $parsedQuery = $wgParser->transformMsg($query, $options); > >+ > >+ // Return the parsed query > >+ return $parsedQuery; > >+ } > This could be shortened drastically to just return > $wgParser->transformMsg($query, $options); . You should use > $wgParser->preprocess() instead, though, since transformMsg() uses $wgTitle > (which is null, which'll probably cause nasty errors). > >From what I've read in the comments, I'm supposed to use transformMsg from the outside of the parser. And without ParserOptions, the function doesn't work. Also, preprocess() expects a $title as well. Also, changed it to be protected - I think it's good that parseQuery is overridable. > >+ public function getAllowedParams() { > >+ return array( > >+ "_query" => array( > I don't get why underscores are used here. If you really want every parameter > to look like &ask_foo, you should set your prefix to "ask_" instead of "ask"; > parameter names with underscores in them aren't used in the core API, though. I changed the prefix instead, indeed. I think asksortorder doesn't look as good - but if it's against the naming convention I can change that. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
