Brion Vibber schreef:
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:
- There's a backend ("controller") class for performing edits. This has
hook points for things like aborting or altering edits (spam checks, captcha, etc)
- 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")
- 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! :)
Yup, EditPage is a nightmare. I have a half-written Edit class lying around that's supposed to contain the backend part of EditPage. It's far from complete, however, and currently on hold. I'd be happy to send anyone interested in continuing that rewrite before I do (which could take some time) my unfinished work.
About the hooks: most hooks should be in the backend, yes. However, extensions like ConfirmEdit need to return certain information (CAPTCHA URLs) to the user. There's a UI hook to do that in the UI, and there's an API hook to return that information to API users. Now CE is kind of unique that way, and the API does honor most hooks in EditPage.php, it just doesn't provide a way to pass a meaningful error message back to the user. The problem here is that since EditPage doesn't properly separete UI and backend, neither do its hooks. For instance, the hook that checks whether an edit is spam is supposed to come up with an HTML (!) error message, which it has to insert into the EditPage object somewhere. Of course that's deeply evil from the API's perspective. There's a similar issue with the upload code (actually, it's even worse) which necessitates a big rewrite before an action=upload module can even be written. Luckily (for me), Bryan committed to that task (thanks again).
The recurring theme here is that phase4 (if we ever go there) requires a rethinking of EditPage.php (and SpecialPreferences.php, BTW).
Roan Kattouw (Catrope)