dan_the_man at telus
Aug 22, 2008, 1:49 AM
Post #30 of 32
(524 views)
Permalink
|
|
Re: Special:All pages broken at about 03:00 UTC this morning
[In reply to]
|
|
I'm actually working on refactoring the EditPage class.
My goals are a bit different, but they still do require some more
organization in EditPage.
I'm trying to make EditPage expendable. Currently the EditPage has so
much different stuff mixed in different areas of the class that it's
impossible to override a small area of it inside of a subclass. ie: A
different type of edit page, such as SF's formedit.
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)
Brion Vibber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aryeh Gregor wrote:
>
>> On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw <roan.kattouw [at] home> 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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
