« Return to Thread: Special:All pages broken at about 03:00 UTC this morning

Re: Special:All pages broken at about 03:00 UTC this morning

by Brion Vibber-3 :: Rate this Message:

Reply to Author | View in Thread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aryeh Gregor wrote:

> On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw <roan.kattouw@...> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkisaV8ACgkQwRnhpk1wk47AswCgxnUPZhA5+Kxg0tuGdxJ0Z19q
SIEAoKNhI5/SCjIE8tqDPmPTGprwmcW8
=nPgB
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 « Return to Thread: Special:All pages broken at about 03:00 UTC this morning