On Wed, Mar 12, 2008 at 11:22 AM, DanTMan <dan_the_man(a)telus.net> wrote:
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.
Are "RealName" and "KeyName" the best terms to use? We already use
"Text" and "DBKey" for titles, but I recall that confused me somewhat
for a while. I would probably have done "DisplayName" and
"NormalizedName", but that might not be ideal either. We may as well
think about this now instead of being stuck with weird names forever.
^_^ 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).
Oh, that's very neat. It preserves a one-to-one correspondence
between usernames and User-namespace titles -- almost. Are you going
to do stuff like ban '@' and other things not allowed in usernames
from the namespace? That would make it a perfect bijection between
User pages and user names-plus-IP addresses.
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.
Hmm, I see. When would this be a concern? Shouldn't the page_real be
generated from the URL? I guess not exactly, if link targets are
normalized. I'm thinking if the user types, I dunno, "str_repeat"
into the search box, they should get links asking them to edit
"str_repeat", not "str repeat" or any other variant. The same should
apply to ordinary wikilinks, ideally -- but on the other hand,
non-broken wikilinks should still point to prettified locations. So I
guess this would require [[has space]] to translate to
?title=Has_space (or whatever normalized form) if it exists, but
?title=has%20space&action=edit if it doesn't. Which isn't perfect.
But I don't see any other way to achieve the effect.