On Wed, Aug 20, 2008 at 11:58:39AM -0700, Brion Vibber wrote:
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.
So the obvious followup question is: is there a plan to migrate the front end to *use the API* to talk to the backend (which is the preferred approach to such things anyway)?
Cheers, -- jra