On Wed, Aug 20, 2008 at 3:58 PM, Robert Ullmann rlullmann@gmail.com wrote:

It is now broken, and should be put back. (In particular, the python wikipedia framework has been broken.)

The User Interface is designed for users. The python Wikipedia framework, therefore, should use the API, and then it won't have these problems.

Anyone developing automated software which interfaces with MediaWiki should be subscribed to this list. And for any such person, this thread should be enough of a red-flag for them. The API has existed for awhile, and the UI should not be depended on for any automated things.

~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)

Robert Ullmann wrote:

Quite so. However, it doesn't. And a *very* large amount of stuff is built on it. Would be good to fix it. Before changing the UI it relies on.

Question: How would the people maintaining it have known that it was going to be broken this morning?

Is easy to fix, took me < 3 minutes to fix my copy of wikipedia.py (mostly deleting code ;-).

But everyone else using the allpages generator will be stuck, and almost all will have no clue what is wrong or how to fix it.

On Wed, Aug 20, 2008 at 10:17 AM, Andrew Garrett andrew@epstone.net wrote:

...

On Wed, Aug 20, 2008 at 3:58 PM, Robert Ullmann rlullmann@gmail.com wrote:

...

It is now broken, and should be put back. (In particular, the python wikipedia framework has been broken.)

The User Interface is designed for users. The python Wikipedia framework, therefore, should use the API, and then it won't have these problems.

-- Andrew Garrett

---

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

Brion Vibber wrote:

Robert Ullmann wrote:

...

Quite so. However, it doesn't. And a *very* large amount of stuff is built on it. Would be good to fix it. Before changing the UI it relies on.

Question: How would the people maintaining it have known that it was going to be broken this morning?

They have known for the past SEVERAL YEARS that UI COMPONENTS FREQUENTLY CHANGE and they should use MACHINE-READABLE APIS, as they have been told repeatedly OVER THE YEARS.

...so where's the edit API?

(Yeah, I know. But my real point is, you'll have a hard time convincing people that the API is actually a finished product ready for prime time as long as its feature set, as enabled on Wikimedia sites, has a huge gaping hole like that.)

"Brion Vibber" brion@wikimedia.org wrote in message news:48AC45CE.8060308@wikimedia.org...

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

Ilmari Karonen wrote:

...

Brion Vibber wrote:

...

Robert Ullmann wrote:

...

Quite so. However, it doesn't. And a *very* large amount of stuff is built on it. Would be good to fix it. Before changing the UI it relies on.

Question: How would the people maintaining it have known that it was going to be broken this morning?

They have known for the past SEVERAL YEARS that UI COMPONENTS FREQUENTLY CHANGE and they should use MACHINE-READABLE APIS, as they have been told repeatedly OVER THE YEARS.

...so where's the edit API?

Why is an edit API needed for reading a list of page names? Oh wait, it isn't! :)

That, of course, is not the point at all. The point is, why invest large amounts of time and effort in developing a bot framework to use an API that isn't yet complete?

Russell Blau wrote:

"Brion Vibber" brion@wikimedia.org wrote in message news:48AC45CE.8060308@wikimedia.org...

...

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

Ilmari Karonen wrote:

...

Brion Vibber wrote:

...

Robert Ullmann wrote:

...

Quite so. However, it doesn't. And a *very* large amount of stuff is built on it. Would be good to fix it. Before changing the UI it relies on.

Question: How would the people maintaining it have known that it was going to be broken this morning?

They have known for the past SEVERAL YEARS that UI COMPONENTS FREQUENTLY CHANGE and they should use MACHINE-READABLE APIS, as they have been told repeatedly OVER THE YEARS.

...so where's the edit API?

Why is an edit API needed for reading a list of page names? Oh wait, it isn't! :)

That, of course, is not the point at all. The point is, why invest large amounts of time and effort in developing a bot framework to use an API that isn't yet complete?

I've been using the read API for at least a year, in a custom framework of my own design. It's easier to use than screen-scraping, uses less bandwidth for both the host and, client, it's stable, and it's faster. There's every reason in the world to use it, including that you don't have to worry about the UI changing by surprise at 3AM.

SQL

On Wed, Aug 20, 2008 at 1:58 PM, Victor Vasiliev vasilvv@gmail.com wrote:

Yes, you just have to worry that query.php is replaced with api.php, which may be then replaced with something else. And also, I went through the mediawiki-api archives and found about 9 breaking changes for API. Pretty stable, isn't it? :)

I don't understand why there are ever breaking changes in the API. THE API SHOULD NEVER EVER EVER CHANGE. IT SHOULD BE A STABLE INTERFACE. There needs to be a policy, set in stone, not negotiable, that behavior for a given API query should NEVER change in an incompatible fashion. If something is inconsistent it should be deprecated and a new function instituted to replace it. The old deprecated way could then be marked for a few years (say, three years, or at least one year) before finally being removed. Authors of bot frameworks should be encouraged to write code checking for <deprecated> or whatever and having their framework raise a warning of some kind to inform them that they should update it.

This really seems like a no-brainer to me. But, I'm not an API developer, so . . .

On Wed, Aug 20, 2008 at 7:58 PM, Victor Vasiliev vasilvv@gmail.com wrote: [...]

And also, I went through the mediawiki-api archives and found about 9 breaking changes for API. Pretty stable, isn't it? :) --vvv

---

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

But far less recently. The API has been in development phase for the last two years or so with many modules added over time which were not all as consistent as we would want it to be. But I think now that we are entering a more stable phase where large portions that need to be covered are covered and not much change can be expected.

As for the edit api I'm not really sure whether it is ready. It has been some time that I last looked at it. If I remember correctly there are still some problems left with hooks that I'd rather see fixed. I did fix some myself some time ago but I don't recall whether I fixed all of them.

Bryan

On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw roan.kattouw@home.nl 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.

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)

Aryeh Gregor schreef:

On Wed, Aug 20, 2008 at 3:08 PM, Roan Kattouw roan.kattouw@home.nl wrote:

...

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.

What you *should* have is a backend hook that allows cancellation of an edit, with some way of passing back an error condition that can be displayed by both the human UI and the API.

Come to think of it, letting the hook pass a message key and letting the extension add that message key to ApiBase::$messageMap as well seems like a good idea. Still, we'd be breaking dozens of extensions that way. I'd like some input from chief developers (you, Brion, etc.) before I do that.

Roan Kattouw (Catrope)

Aryeh Gregor schreef:

Well, I don't think I qualify as much of a "chief developer". Especially not to be listed before Brion. :P

What I kind of meant is that you provide useful comments on pretty much everything you see.

Roan Kattouw (Catrope)

On Wed, Aug 20, 2008 at 11:58:39AM -0700, Brion Vibber wrote:

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.

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

Aryeh Gregor schreef:

On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth jra@baylink.com wrote:

...

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)?

One practical issue with this at present is that nobody who does much of anything with core does much of anything with the API. I've barely looked at it at all.

True. Actually, there's a pattern of isolation here. While pretty much all developers are familiar with the 'core' classes (Title, Article, Revision, etc.), very few are familiar with isolated ones such as the parser, the API, the image handling code, the Database abstraction layer (except for select() and similar functions)

As a more philosophical thing, there's no reason for the human UI to call the API. We should have a back-end, and then two interfaces to that: one designed for external robots, and one designed for HTML-viewing humans. Both of the interfaces should use the internal PHP interface to speak to the back-end. The API operates in a format that's suitable for robots to use, not suitable for internal code to use.

Simetrical is right here: the UI and the API call the same functions, and display the results in different ways. That's exactly why there's no sense in migrating the front end to the API (and that's just forgetting about the HTTP overhead involved).

Roan Kattouw (Catrope)

On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson wilson.jim.r@gmail.com wrote:

Jay said:

...

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)?

There are times when utilizing the API programatically could make extension development much easier. The last time I looked at the API certain things were hard coded (such as bot limits - yuck) which made it tough/impossible to use in certain extension scenarios. I believe these have been corrected though, so it's probably a good resource for certain classes of extensions.

Someone familiar with the core could always construct a proper $dbr->select() querys, but it would be easier (read: less code) in some cases to let the API classes handle it.

-- Jim R. Wilson (jimbojw)

On Wed, Aug 20, 2008 at 3:20 PM, Roan Kattouw roan.kattouw@home.nl wrote:

...

Aryeh Gregor schreef:

...

On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth jra@baylink.com wrote:

...

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)?

One practical issue with this at present is that nobody who does much of anything with core does much of anything with the API. I've barely looked at it at all.

True. Actually, there's a pattern of isolation here. While pretty much all developers are familiar with the 'core' classes (Title, Article, Revision, etc.), very few are familiar with isolated ones such as the parser, the API, the image handling code, the Database abstraction layer (except for select() and similar functions)

...

As a more philosophical thing, there's no reason for the human UI to call the API. We should have a back-end, and then two interfaces to that: one designed for external robots, and one designed for HTML-viewing humans. Both of the interfaces should use the internal PHP interface to speak to the back-end. The API operates in a format that's suitable for robots to use, not suitable for internal code to use.

Simetrical is right here: the UI and the API call the same functions, and display the results in different ways. That's exactly why there's no sense in migrating the front end to the API (and that's just forgetting about the HTTP overhead involved).

Roan Kattouw (Catrope)

---

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

---

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

PrefixSearch does it (around line 130).

-Chad

On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson wilson.jim.r@gmail.com wrote:

There are times when utilizing the API programatically could make extension development much easier. The last time I looked at the API certain things were hard coded (such as bot limits - yuck) which made it tough/impossible to use in certain extension scenarios. I believe these have been corrected though, so it's probably a good resource for certain classes of extensions.

Someone familiar with the core could always construct a proper $dbr->select() querys, but it would be easier (read: less code) in some cases to let the API classes handle it.

That's functionality that the backend should provide, not the API. At least IMO. The API is primarily a bot interface, not a PHP interface. Trying to use it as a PHP interface as well will require a lot of contortions, since there are fundamental differences between the desirable traits of each type of interface:

* The level of access that bots and scripts can have. Bots get carefully limited access, while extensions have unlimited read/write access. This means that if the API is primarily targeted at bots, it will have limited write access, and *very* limited support for administrative functions that extensions may very well want to invoke. For instance, the userrights module was removed on principle, last I checked, as something that we didn't need the security risks of given that bots are unlikely to ever need to change user rights. * The format of access. Bots use HTTP requests, while extensions use direct function calls. HTTP requests are text-only, and consist of one of a very small number of filenames plus an arbitrary associative array mapping string parameters to string values. Function calls support a rich variety of data types, and consist of any of a potentially very large number of individual functions plus a small, fixed ordered list of parameters. Trying to shoehorn one access format into another will require contortions like FauxRequest. * The cost of access. HTTP requests have very high overhead -- set up network connection, pass request through a long chain of servers and processes, send result back -- usually on the order of a hundred milliseconds or more. Function calls have very low overhead, without even a context switch: likely well under a microsecond. Moreover, HTTP requests are stateless, while a function-call-based interface can maintain extremely rich state. These push the format and nature of a bot API in a very different direction from that of an extension API. A bot API will tend to encourage a small number of elaborate requests, because the state must be built on every request. A good extension API, on the other hand, allows many small function calls, reusing state (such as already-initialized objects) as often as possible, with each function doing one thing. Again, these cannot be cleanly reconciled.

Although I'm not an extension author, and you are, I don't *think* you want to use the API, now or ever. I think what you want is a clean separation between backend and frontend. You should then be able to call the backend functions directly, and they'll provide you with clean functionality like "perform an edit by this User object to this section number of this Article object with this text, with(out) usual permission checks, returning an easily-parsed array of errors and warnings if any occur".

On Thu, Aug 21, 2008 at 6:03 PM, Jay R. Ashworth jra@baylink.com wrote:

As soon as I read this, i realize that indeed, you guys are talking about "an implementation of an interface to the API", not the actual thing itself.

An API, by definition, is a declared set of call and response interfaces to a block of core code, with defined parameter domains and ranges.

It's not the interfaces you use to *get* to that, be it HTML, REST, or whosoever...

When we say "API" we mean "bot API", i.e., "a web-based API provided for third parties to read data from (and possibly write data to) the wiki in a programmatic fashion, either anonymously or via a user account". This is in context to the human UI, which is meant to provide the same functions but to humans, not computer programs. This is how the term is often used in web contexts these days.

We do *not* mean a programming API, i.e., a set of classes, methods, and functions that MediaWiki itself and its extensions can call. That's what we often call the "backend". api.php uses the backend, as do the usual index.php and other human access methods.

The issue is that historically, the only access to the backend was through the human UI, or via extensions (but those can always hack things up by running queries directly and so on). Therefore there was a lot of careless mixing of UI and backend code. The existence of the bot API is forcing some of this mixing to be fixed, which incidentally improves things for extensions too. So the API is incidentally related to separation of interface logic from business logic -- but the API itself is supposed to only contain interface logic, for remote bot access.

Nikola Smolenski schreef:

Aryeh Gregor wrote:

...

On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson wilson.jim.r@gmail.com wrote:

...

There are times when utilizing the API programatically could make extension development much easier. The last time I looked at the API

Although I'm not an extension author, and you are, I don't *think* you want to use the API, now or ever. I think what you want is a clean

As an extension author, I can say that in one of my extensions I have used the API to great satisfaction of everyone :)

Using the API internally is useful in some cases, yes. If you're gonna run a complex query the API happens to support, you're usually better off using the API, to prevent code duplication. But while there are bound to be places in the code where the API is used internally (which doesn't have the HTTP overhead I mentioned earlier, my mistake) in the core, in extensions and even in the API itself, there's no reason for the core to systematically use the API for everything.

Roan Kattouw (Catrope)

Jay R. Ashworth schreef:

On Wed, Aug 20, 2008 at 10:20:44PM +0200, Roan Kattouw wrote:

...

Simetrical is right here: the UI and the API call the same functions, and display the results in different ways. That's exactly why there's no sense in migrating the front end to the API (and that's just forgetting about the HTTP overhead involved).

Um, we mean different things by "API", clearly.

What I think *you* mean by it is "a thin wrapper over the *actual* API".

Am I wrong?

In MediaWiki speak, the API is api.php . You're probably referring to the backend functions which *are* used by the UI.

Just to clarify again: the API and the UI call *the same functions*, but present the results differently. That's why there's *nothing to gain whatsoever* in letting the UI call the API.

Roan Kattouw (Catrope)

On Fri, Aug 22, 2008 at 12:01 AM, Roan Kattouw roan.kattouw@home.nl wrote:

Just to clarify again: the API and the UI call *the same functions*, but present the results differently. That's why there's *nothing to gain whatsoever* in letting the UI call the API.

In theory...

On Fri, Aug 22, 2008 at 2:02 AM, Jim R. Wilson wilson.jim.r@gmail.com wrote:

On the other hand, if you consider the supporting PHP classes through which api.php makes its calls as part of "the API" then I still contend that there are probably cases where it would be easier or simpler (or both) to just use it than say construct all the database queries onesself.

Those are what I'm calling the "backend", which is supposed to be called separately by both the human UI and the bot API. As well as any extensions.

On Fri, Aug 22, 2008 at 2:51 AM, Nikola Smolenski smolensk@eunet.yu wrote:

As an extension author, I can say that in one of my extensions I have used the API to great satisfaction of everyone :)

Which one?

On Fri, Aug 22, 2008 at 4:40 AM, Roan Kattouw roan.kattouw@home.nl wrote:

Using the API internally is useful in some cases, yes. If you're gonna run a complex query the API happens to support, you're usually better off using the API, to prevent code duplication.

So why does the API have any logic to do anything except translate the HTTP query into backend functions and display the results? If you have a lot of internal logic anywhere, that other callers would like to use, I suspect that would be best moved into the actual classes somehow. It's the same as with the human UI: you shouldn't (ideally) be mixing business logic with logic for a specific output type.

Aryeh Gregor schreef:

On Fri, Aug 22, 2008 at 4:40 AM, Roan Kattouw roan.kattouw@home.nl wrote:

...

Using the API internally is useful in some cases, yes. If you're gonna run a complex query the API happens to support, you're usually better off using the API, to prevent code duplication.

So why does the API have any logic to do anything except translate the HTTP query into backend functions and display the results? If you have a lot of internal logic anywhere, that other callers would like to use, I suspect that would be best moved into the actual classes somehow. It's the same as with the human UI: you shouldn't (ideally) be mixing business logic with logic for a specific output type.

That's probably laziness caused by the fact that the API implementation predates the code that uses FauxRequest.

Roan Kattouw (Catrope)

Daniel Friesen schreef:

;) And then there are a few of us who get intimate with a fair percent of the complex and isolated interfaces, enough to scare themselves. T_T Some time ago, I came to realize that I had actually started to grasp an understanding of how the Parser worked. The preprocessor as well. Nearly all my new ParserFunctions use SFH_OBJ_ARGS and some even do scary things with the frames. When someone asks what function to use in a hook or a tag to do something with the parser, I actually understand what part of the parser will best do that for them (Without needing to trudge around the functions and make a bad guess), and even worse... T_T I'm actually rewriting a portion of the parser myself... And I'm starting to make use of parseresque code in my own work.

As for the other, anyone remember my rewrite of the Database class's titleName method. And my suggestion for a doQuery arg (though that was changed into a backend function that works with strings).

Actually, I'm building my own Database library. Heh, now that's the scary portion. I even implemented Brion's idea for a RawSql class ( Trust me ;) it works quite nicely, it even inspired the RawMarkup class inside of my markup abstraction library (similar to the Xml class))

You're welcome to help out us API devs, if that's your next step ;)

Roan Kattouw (Catrope)

Daniel Friesen schreef:

Heh, perhaps... ^_^ Though I'm more likely to do some DB+API evil and attempt to eliminate all the hardcoded SQL inside of the API.

Save your time, it's been eliminated already AFAIK.

Though, to say the truth I don't know how well I'd fit in the API. I honestly have a strong dislike of supporting real old things. While I do try to keep backwards compatibility in the rest of MediaWiki, there are many cases where where we break things for the extensions that interact with the software.

Hearing that, the idea of having you as API lead developer does sound scary (no offense).

Roan Kattouw (Catrope)

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@home.nl 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-----

It might do a bit of a better job of it. I'm actually thinking of putting the preview parsing stuff (just the parserOutput) into the initialization rather than arbitrarily calling a function which mixes UI and other stuff.

Though, I may be doing a bit more work in the UI area than a simple UI backend split. I'm actually splitting up the different areas of the UI so that parts can actually be overrided rather than needing to override and duplicate an entire large function in a way which may cause issues when some of that code is changed in future revisions.

~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)

Roan Kattouw wrote:

Daniel Friesen schreef:

...

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.

If that results in a clean separation of UI and backend code, it would probably solve my problem.

Roan Kattouw (Catrope)

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

Aryeh Gregor wrote:

On Wed, Aug 20, 2008 at 1:58 AM, Robert Ullmann rlullmann@gmail.com wrote:

...

Like this:

http://en.wiktionary.org/wiki/Special:AllPages/Hill

used to display 480 titles starting at "Hill". Now it does what PrefixIndex does. If I wanted that, I'd use Prefixindex. How do we get access to the original function? (And I don't understand the bit about "excessively long output" at all, it always displayed 480 titles (except at the end of the wiki).

As far as I can tell, formerly the URL you gave did nothing at all.

You're incorrect.

- -- brion

Aryeh Gregor wrote:

On Wed, Aug 20, 2008 at 1:58 AM, Robert Ullmann rlullmann@gmail.com wrote:

...

http://en.wiktionary.org/wiki/Special:AllPages/Hill

As far as I can tell, formerly the URL you gave did nothing at all.

This is wrong. It used to list all pages, starting at Hill. There were links to the previous and next page of the large listing of all pages.

r39427 http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=39427 appears to have allowed subpage syntax to be used for AllPages;

Yes, so it seems if you compare to the immediately previous version. But that is the 3rd commit (by aaron) that day. If you go back to the older version (revision 36481, June 19), there is a similar statement isset($par), which calls showChunk() rather than showPrefixChunk().

The old implementation might have drawbacks, but the new version is too different in function.

Aaron Schulz wrote:

The format changed to avoid excessively long output. I've looked at the form and those links on wiktionary and don't see anything incorrect or not "working".

Changing Allpages to Prefindex doesn't accomplish this. Much shorter lists than before are now returned for unusual prefixes, such as "Kinematic". But I can still request a Prefindex for "A" and get 350 (?) links listed. Apparently there is both a change in behaviour (from Allpages to Prefindex) and a limit (to 350 links), and the desired result is achieved by the limit, not by the changed behaviour.

A better solution would be to provide a limit of 200 or 350 links in the output, but keeping the old behaviour of Allpages.

Especially, the ability to step *back* as well as forward in that list can be very useful, when you're looking for alternative spellings of a non-existing page name. After searching for Kinematics, I need to step backwards to find Kinematic diagram.