-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aryeh Gregor wrote:
On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw roan.kattouw@home.nl wrote:
About enabling the edit API on Wikipedia: I think it's ready to go. The only real problem it currently has is that action=edit doesn't handle aborts by hooks too well; the edit will be aborted, but the client will only get a vague "A hook aborted the action" (or something along those lines) error. A hook that allows for aborting the edit with a meaningful error message has been added (APIEditBeforeSave), but AFAIK it's currently only used by ConfirmEdit (and only because I migrated it myself). Similarly, extensions influencing other actions may rely on UI hooks that the API bypasses altogether.
Um, why are you adding an API-specific hook for this? Shouldn't it be a backend hook? I'm not sure why there should be *any* API hooks, actually, since the API should just be presenting backend information in a standard format. Extensions should never want to change the format that's returned, as far as I can imagine, since it's supposed to be uniform across all wikis. They should only want to change the actual info, which should be done on the backend level.
The way it _should_ be working is something like this:
1) There's a backend ("controller") class for performing edits. This has hook points for things like aborting or altering edits (spam checks, captcha, etc)
2) There's a frontend ("view") class for handling the HTML edit form. This has hook points for customizing the form output, checking custom input, and presenting UI for error conditions ("you hit spam!" or "you need to submit this extra form")
3) There's another frontend ("view") class for handling the API's edit interface. This _might_ also have hook points for handling special input/output and custom error formatting, though _ideally_ such stuff should be able to use existing I/O channels specified in the API (spam hit just raises an error conditions; captcha hits have an existing channel for saying "show this and respond to it").
Currently the EditPage class mixes a fair chunk of backend and UI, as do the edit filter hooks for spam blacklisting, CAPTCHAs, etc, so it's a bit icky. There's been some refactoring in the course of creating the edit API (as there was much refactoring to Special:Userlogin when the API's login modules were being created), but it remains incomplete.
(At least the raw page data storage model isn't mixed into EditPage! :)
- -- brion