| • bzimport | |
| Sep 13 2005, 1:19 AM |
| F2310: SpecialAllpages.php.patch | |
| Nov 21 2014, 8:49 PM |
Author: Astronouth7303
Description:
The special pages should be able to be read by an application (such as a non-web
client), whether it be in XML, RDF, or some other format.
This obviously excludes Special:Export and Special:Import.
Version: 1.5.x
Severity: enhancement
Astronouth7303 wrote:
Special:Allpages implementation (for XML)
This is the first of several patches implementing this bug using XML. They are
triggered by including "xml=yes" in the URL query.
This one handles Special:Allpages. It returns exactly the same information as
HTML (this includes initial range lists and such). None of the logic has
changed.
Also, in XML mode, it returns an HTTP status code of 300 Multiple Choices for
range listings (in addition to a flag in the XML).
attachment SpecialAllpages.php.patch ignored as obsolete
The special cases everywhere in this code are pretty ugly and will be
hard to maintain.
I'd recommend reworking this to a model-view system, with separate
classes for handling HTML output and XML output, both separate from the
database-reading work.
Astronouth7303 wrote:
(In reply to comment #2)
The special cases everywhere in this code are pretty ugly and will be
hard to maintain.I'd recommend reworking this to a model-view system, with separate
classes for handling HTML output and XML output, both separate from the
database-reading work.
I'll see what I can do with that. Currently, that special page is not OO, just a
collection of functions.
What I'm thinking is create a "PageLister" class (not final name!) and implement
it for XML and HTML. Pass it to each of the functions, etc.
Astronouth7303 wrote:
Special:Allpages implementation (for XML)
Added object described. Should be working. (Although such extensive changes
should be tested.)
Attached:
Please compare with Bug #3676, where I provided a patch for adding CSV support
to most special pages with minimal effort.
Astronouth7303 wrote:
(In reply to comment #5)
Please compare with Bug #3676, where I provided a patch for adding CSV support
to most special pages with minimal effort.
I should note that unlike CSV, this is geared towards applications that can use
XML with great ease (eg, AJAX apps). This is not only bots, but client-side
readers as well.
XML is also less ambiguous. You can specify exactly what each piece of data is,
instead of infering that from it's position relative to other data.
There is place for both. (CSV is simpler, XML has more well-distributed APIs.)
Cooperation betweeen these two ideas would be very good. (gen=xml?)
robchur wrote:
I suspect we want to phase this out in favour of the new machine-readable API.
Astronouth7303 wrote:
Sure. Then make this a tracking bug for special pages that do/don't comply.
My concern is that if the data itself isn't easily parsed, then it amounts to
glorified screen-scraping.
If the API is directed at articles (in wikitext), then how do special pages fit
into it?
(In reply to comment #8)
If the API is directed at articles (in wikitext), then how do special pages fit
into it?
The API currently implements something similar to Special:Allpages (but with more filtering options), and most other special pages (or derivations thereof) are also implemented.