Author: cnit
Description:
I've defined getCustomPrinter() in my extension's class derived from ApiQueryBase. However, it's simply not being called, even though, both ApiBase class and ApiQuery define this method and ApiQueryBase extends ApiBase.
Because of that, I am forced to use &export and &exportnowrap parameters, which are unnecessary (extra bloat) in my case.
There must be something flawed in this logic, I think so.
Version: 1.15.x
Severity: normal
Query submodules can be called in conjunction with other query submodules, like so:
api.php?action=query&list=allpages&meta=siteinfo|userinfo&prop=info|revisions
In this case, if your module would switch to a custom printer, the others would quite likely freak out. Architecturally, the ApiQuery class is the main module being called and it is ApiQuery that determines the custom printer etc.; it only calls ApiQuery* classes to populate parts of its result, but those classes aren't fully-fledged modules.
cnit wrote:
Thank you. I should try inherit ApiBase instead. Didn't think about the possible conjunction of ApiQueryBase instances.
cnit wrote:
However, now setContinueEnumParameter() became unavailable, too. Shall I re-define it in my own class which extends ApiBase now, or there is a better approach?
cnit wrote:
Also ApiQueryBase has a lots of nice SQL expression building methods, they're all not unavailable when deriving from ApiBase :-(