Reported by TWiki:Main.EricHanson as http://twiki.org/cgi-bin/view/Support/DakarViewSeemsGlobalVsLocal

Because of the changes to support hierarchical webs, then if you have a squab like this:

[[Bugs]]

then it will always find the web Bugs before the local topic Bugs.

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.

CC

From a user's perspective it is only logical that a lonely [[Bugs]] 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.

-- PTh

Added unit test in HierarchicalWebsTests 11444 (currently fails)

CC

See also Item2871

MD

---

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 (WebName.)?TopicName(#Anchor)? where TopicName 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
• else
  • 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
• else
  • 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.

CC

We are talking about TWiki::Render::_handleSquaredBracketLink(), and the amount of extra logic that is in there compared to the work already done by subsidiary functions, most notably TWiki::normalizeWebTopicName() and TWiki::Render::internalLink().

Status quo is that _handleSquaredBracketLink is analyzing a string to find out which of it is the web and which the topic part. This is essential to find out the target of the link. The link text is assigned in internalLink 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 normalizeWebTopicName() 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 (.*)\.(.*?) where $web = $1; and $topic = $2; If $web is not defined it is the current web. Note, that there's no way that a string could be analyzed as being web1.web2 because web2 is taken as a topic.

The current code in _handleSquaredBracketLink includes expensive extra trickery only used if hierarchical webs are enabled to extend the web-topic normalization in normalizeWebTopicName() (used via Func 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 links is

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.

MD

Please be very careful, do not change the current spec for top level webs. In particular, these rules apply:

You type	Label shown	Comment
Someweb.SomeTopic	SomeTopic
Someweb.WebHome	• WebHome (if in Someweb web) • 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.

-- PTh (copied from Item2871)

The solution is even simpler than what Micha proposed.

LitterTray.Subweb.WebHome	LitterTray.Subweb.WebHome
LitterTray.WebHome	LitterTray
LitterTray.Subweb.OldTopic	LitterTray.Subweb.OldTopic
LitterTray.Subweb.NewTopic	LitterTray.Subweb.NewTopic
LitterTray.OldTopic	OldTopic
LitterTray.NewTopic	NewTopic
[[LitterTray.Subweb.WebHome]]	LitterTray.Subweb.WebHome
[[LitterTray.WebHome]]	LitterTray.WebHome
[[LitterTray.Subweb]]	LitterTray.Subweb
[[LitterTray.Subweb.NewTopic]]	LitterTray.Subweb.NewTopic
[[LitterTray.Subweb.OldTopic]]	LitterTray.Subweb.OldTopic

CC

4.1.0 released

KJL