roan.kattouw at home
Aug 20, 2008, 12:08 PM
Post #21 of 32
(892 views)
Permalink
|
|
Re: Special:All pages broken at about 03:00 UTC this morning
[In reply to]
|
|
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:
>
> 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! :)
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)
_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
1
