Rowan Collins wrote:
Yes, I get the idea of having them conceptually
attached to the
article, but in terms of implementation this raises some complex
issues:
I think most of those questions are quite easy to answer once you
realise that (a) 99% of people looking for a topic do so via the search
box, not the URL; (b) when someone links to an article, they do it via
the URL, not the search box. Hence:
* How do you deal with the fact that a given title can
be both an
article in its own right, and an alias defined by another article?
The URL should display the article. The search box should give a
selection of both possibilities.
* How do you keep the code efficient if it has to
check two places
(the list of redirects and the list of actual pages) every time it
wants to look up a title?
Caching.
* If you abandon the current "redirect created by
magic page content",
how do you convert a page to an alias, or vice versa?
You don't "convert" a page to an alias; you just create the alias, and
independently of that, delete the page (if that is what you want to do).
Similarly, removing an alias and creating a page should also be separate
actions.
* What happens when somebody tries to create an alias
which is already
a page, or which is already an alias for something else?
The alias gets created as always. Now if someone searches for the alias,
it should (obviously) list all the pages that have this alias. The same
should probably happen to the URL if there is no actual page at that
title; although I wouldn't mind having the URL display the "page does
not exist" screen so that it is easier to create a page at that title.
* What happens when you remove something from the list
of aliases?
The alias gets removed. Duh. :-) We already have this happening with
categories.
(you can't create an alias, because there's a
page there / you can't
create a page, because there's an alias there)
No, such arbitrary limitations are unnecessary.
Timwi