I think clear rules are still missing on how an arbitrary link is
translated into a WikiName. These should really be tight rules like
you already wrote about MediaWiki:
Hm? I thought I wrote the rules out already... What is missing,
to be
exact?
Regarding backwards compatibility, I'd recommend ignoring old
special
cases (where existing) in favor of allowing for simple rules for
3.0+.
I thought that's what I said in the proposal :)
The only thing really to wonder about is the english plurals -
setting.
There's some annoying magic in ReferenceManager to make sure that
"TestPage" and "TestPages" are considered same objects.
Especially the hidden platform dependencies, which are obviously
existing in the file-based provider up to 2.8 should be eliminated.
These are more or less errors, not really features.
* The simple way: Implement some fallback rules in wiki page
lookup in
order not to break existing links. If feasible, the
corresponding code
should be marked as being for this purpose only.
Problem: What if some old link isn't valid any more and therefore
gets permanently redirected by this code? Then, someone creates a
new page whose name is just this old link's name. This would break
the old link without touching it directly.
Could you elaborate on that? The current recommendation to create
links
(2.8) is to simply put them inside brackets. For example, [This
is a page]
creates a link to a wikipage called "This is a page". In 2.4 and
previously, this would actually create a link to "ThisIsAPage".
Our current implementation checks first for the existence of "This
is a
page", and then for backwards compatibility reasons, "ThisIsAPage".
However, internally, these pages are not considered the same, so
it is
possible to create "This is a page" even when "ThisIsAPage"
exists, and the
new page will then take precedence.
Because *most* of the links at jspwiki.org are these backwards
compatible
forms, I don't think we can throw it away. However, what we can
do is to
make it a configuration item.
* If the simple way isn't feasible, implement a migration tool which
converts the page names and links in existing repositories.
That may be really difficult to do (he said, having just watched one
corporate migration where things were renamed automatically).
Besides,
since it modifies the repository, it needs some pretty heavy-duty
testing.
The export tool can output the names in normalized form, but I'd
hesitate
to change the repo contents itself. Besides, it wouldn't work on
most
plugins, etc.
/Janne
