Simetrical skrev:
Tons of core code will have to be modified to take into account two possible types of redirects. That's aside from the fact that again, I see no reason at all to make two separate systems to handle what amounts to the same problem.
Again, I fully agree, from the technical side of things.
At the lowest level of abstraction, that is, in the form of a UML class diagram one could more clearly point out what, really, the Alias/Synonym idea "is", technically speaking.
Given the following symbols for associations:
-------> : Navigable only one way <>------ : "Has" <.>----- : "Owns" (filled diamond) [class] : Class (name)
== #1 - Existing Redirects ==
We could describe the existing Redirect concept, an article with the redirect clause: '#REDIRECT [[RedirectsTo]]' like so:
[ Page ] [ ]------------------ [ ] | [ ]<-1-RedirectsTo--- [ ]
This diagram shows a "single link", that is, a one way relation (we can disregard the internal 'redirect' table in the db for now), of a separate page (the redirect page) pointing at a target page.
It is important to note that, from a users perspective, the association is "navigable", that is, it goes only one way in that you cannot manage the link from inside the *target* page - which is not always very convenient for the users.
== #2 - Owned Aliases/Synonyms ==
If the association had been an Alias/Synonym instead, the first change we need to make in the diagram is that the association would be made "Owned" (managed) from the target page (but technically it would still remain being a "pure" redirect), like so:
[ Page ] [ ]--------------------- [ ] | [ ]<.><-1-RedirectsTo-- [ ]
Of course it should be possible to have several Aliases/Synonyms, and thus the multiplicity of the relation should be changed from one (1) to many "(*) :
== #3 - Multiple Owned Aliases/Synonyms ==
[ Page ] [ ]----------------------- [ ] | [ ]<.><-*-OwnedRedirects-- [ ]
In this way an article can have many Aliases/Synonyms (= Redirects) which are *Owned* (managed) by the target page. That would be an improvement of the existing concept. And there's no problem with keeping also the existing solution (#1) alongside with the Owned list of Aliases/Synonyms. The final diagram, capturing both concepts could look like this:
[ Page ] [ ]------------------ [ ] | [ ]<-1-RedirectsTo--- [ ] [ ]----------------------- [ ] | [ ]<.><-*-OwnedRedirects-- [ ]
Meaning: A redirect can be a freestanding redirect (current solution) with a link "RedirectsTo---1->" to one other page. A redirect can also be owned by the target page, thus serving as a "listItem" in the OwnedRedirects-list.
The redirect itself could carry information about whether it is "owned" or not.
The class-association Redirect (= existing table) could hold the (additional) attribute IsOwned to distinguish which links can be manually edited (the current solution) and which links can be modified only from the page on which they're defined (perhaps a back link from the redirect page would be good).
[ Page ] [ ]-1-rd_from--------- [ Redirect ] [ ] |------[ IsOwned: ] [ ]-1-rd_title-------- [ ] [ ]
When attempts to create multiple similar Redirects would be made the system simply refuses to (auto)create duplicate entries in the Redirect table in order to maintain "one redirect = one target".
This would be a significant difference/improvement for the users, but (probably) a rather small change technically, I think.
Regards,
// Rolf Lampa