On Wed, Mar 12, 2008 at 11:22 AM, DanTMan dan_the_man@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.