On Sat, Mar 8, 2008 at 10:34 PM, DanTMan <dan_the_man(a)telus.net> wrote:
We've got a few options here:
A) Create a new function getTitle which returns the title object which
the User matches, and make use of it's functions for the standard
displays and other things. Of course this is bascialy the same as
getUserPage.
I don't like this. There's no reason username normalization can't be
stricter than title normalization, for instance. (It had better not
be less strict, of course, if you don't want user page collisions.)
In general I don't like mixing up titles with users. Of course in
practice the backend may use title normalization for users as well,
but that fact should all be hidden in a User method, not exposed to
callers.
B) Change getName's definition to be the display
form of a user's name,
and getTitleKey to be the key form of the user's name. And change the
large number of comparison functions inside of MediaWiki to use
getTitleKey instead of getName.
getTitleKey sounds like a poor name to me.
C) Create a new function getDisplayName, and have
getName's definition
changed to the key form of the user's name, and getDisplayName as the
display form of the user's name. Depreciate the use of getTitleKey
because of it's lack of use or need anymore (changing a single reference
to it). And change the uses of getName as a display value inside of
MediaWiki to use getDisplayName instead.
getName is then ambiguous: which name are you talking about?
getNormalizedName or getNameKey or something would be better.
D) Create two new functions for the key and display
forms of the user's
name. And depreciate the old functions, slowly changing use of them to
the new functions in MW to keep compatibility.
. . . so I would go for (D).
I'm probably in favor of C, as if it's
definition is changed to key
form, all the backend testing and stuff will still work fine, and we
then will only need to worry about changing the areas that the username
is used for display. Which won't really be a problem if we miss
anything, because if we end up missing one conversion, the system will
simply be displaying a semi-ugly form with underscores inside of it and
none of the case stuff picked by the user. And it'll still be likable
and won't break anything in the backend.
Your logic is good, and applies equally to (D): alias getName to
getNormalizedName or whatever, rather than getDisplayName.
Oh, ^_^ an interesting new ability due to switching
to key form:
SELECT user_editcount FROM `user`, `page` WHERE user_name=page_title AND
page_namespace=2 AND page_id=3
In this example, page_id 3 is the userpage of my user's userpage.
What does it do? Well, if you were on the userpage of a user and just
had the page ID, you could now easily grab any information from the
database on that user himself because page_name and user_name are stored
in the same format instead of different formats.
Interesting. Of course, my suggestion above that we don't rely on
user and title normalization being the same would break this. I don't
know if there's any good reason to go either way here.
Oh, minor off topic. But what about putting a
log_user_text in at some
point. Honnestly I know of a few extensions which intended to allow
certain things to be done by anons in addition to normal users, but
which broke when anons were allowed use of them because anon users were
not properly logged.
Yes, please! That's been to-do for ages.