Reported by TWiki:Main.EricHanson
Because of the changes to support hierarchical webs, then if you have a squab like this:
then it will always find the web
before the local topic
It seems more reasonable for it to find the topic. However we have to be very, very careful here, as there is a high risk of breaking hierarchical web names.
From a user's perspective it is only logical that a lonely
links to a topic of that name in the current web. That is, if no web prefix is used, links should point only to the current web.
Added unit test in HierarchicalWebsTests
11444 (currently fails)
See also Item2871
We are talking here about strings in squabs and strings floating in text.
There is no spec for this, and it's obviously essential we have one, so here goes. From the (extremely confusing) Cairo code, the existing plain english function is:
Assume URL links have already been filtered. We are looking at
may include spaces. The #Anchor is always handled the same way, so we can ignore it (assume it is always done).
if there is no WebName
- if TopicName is the name of a topic in the current web
- show TopicName, link to currentweb.TopicName
- else if TopicName is the name of another Web
- show TopicName, link to TopicName.WebHome
- show TopicName?, link to edit currentweb.TopicName
else # there is a WebName
- if WebName.!TopicName is the name of a topic in the WebName web
- show WebName.TopicName, link to WebName.TopicName
- show WebName.TopicName?, link to edit WebName.TopicName
There may be edge cases I haven't shown; if there are, please correct the above. it is very difficult to reverse-engineer the intent from the code. Note:
- the last case does not take account of the possibility that the WebName web does not exist.
- [[!WebName.WebHome]] does not behave the same as WebName.WebHome
I tried to handle the hierarchical web case by extending this algorithm such that WebName could be a hierarchical web specifier. This didn't work because the distinction between Web..Web.Topic and Web.Web.Web isn't clear.
Michael suggests in Item2871
dropping the ability to point to the WebHome in another web simply by citing the web name. That is sensible.
So the change I propose is really, really simple. At the moment the search for the other web is greedy, and will eat all the path components. Simply use the existing algorithm, but make sure at least one path component remains. this last component is always
a topic. This doesn't affect the OtherWeb.WebHome hack.
We are talking about
and the amount of extra logic that is in there compared
to the work already done by subsidiary functions, most notably
Status quo is that
is analyzing a string
to find out which of it is the
and which the
This is essential to find out the target of the link. The link text
is assigned in
and not under consideration here. So
the questions raised by Pth on Item2871
are not part of the problem
right now, as far as I can see.
The most transparent rule, as it is implemented in
is that the last part of a string is the topic being separated by an optional
dot from a web prefix more or less using a simple regex like
$web = $1;
$topic = $2;
is not defined it is
the current web. Note, that there's no way that a string could be
analyzed as being
is taken as a topic.
The current code in
includes expensive extra
trickery only used if hierarchical webs are enabled to extend the web-topic normalization in
in plugins very often). I simply opt'ed to remove this
extra logic completely in Item2871
so that the only thing the code does for bracketted internal
normalizeWebTopicName( $web, $topic );
## removed extra web checks only used for hierarchical webs
return internalLink( $web, $topic ... );
(see attached patch
That's simpler, cheaper and more consistent, IMHO.
Please be very careful, do not change the current spec for top level webs. In particular, these rules apply:
| You type
| Label shown
| • WebHome (if in
• Someweb (if in other web)
| Special case if in other web, so that users can type:
For support visit the Support.WebHome web to get this: For support visit the Support web
We can't change this spec or we would break existing content.
Nevertheless, the spec has not been defined for sub-webs.
(copied from Item2871
The solution is even simpler than what Micha proposed.