Mkay, D it is...
getName will be depreciated...
To go with the whole key/real namescheme I've been going with in
Title.php a new getRealName function will get the name to use for
interface display.
And to match that, getKeyName will get the name for use in uniqueness
checking and comparison, and getName will be aliased to it.
^_^ Actually about your note on User and Title normalization not being
the same. There is no real reason for them not to be (With the exception
of the stuff that we stick in functions like isValidName)...
Why's that? A little bonus I already theorized but never mentioned (I'm
good at grasping a lot of theory and wrapping my mind around how things
work and are supposed to, so I get a lot of them)
Because of the new extensible normalization, and how all the username
stuff relies on getDBkey and directly uses getText for displaying the
username, there is a little bonus.
If you go and extend the normalization of Titles specifically for the
User: namespace (remember that because of the way it's setup, you can
now create per-namespace normalization), the normalization of Usernames
will be directly affected by it (Which is kinda why I needed to alter
User.php because of that login bug).
So, if you go and make the User: namespace completely case-insensitive
and leave other namespaces the way they are, the Usernames will suddenly
all become completely case-insensitive to match that, without altering
any normalization code for usernames.
Btw: I have a function inside of the normalizer.
TitleNormalizer::backconvert( $title ); basically it does the normal
replacing of underscores with spaces. The point of it is for when we
don't have a page_real stored in the database (ie: nonexistant page),
then backconvert will be used to create a temporary title for displaying
while the page doesn't exist. Of course, there is a hook inside of it
which lets extensions override it in case they do something like
changing the ' ' to '_' normalization to ' ' to '-' for
some reason.
Heh, I guess I'll take a look at that log stuff sometime later to see
how easy it will be.
~Daniel Friesen(Dantman) of:
-The Gaiapedia (
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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l