Will the frontend ever use the API, itself?

> 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.