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