• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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

ItemTemplate
Summary Squabs don't find local topic before web
ReportedBy TWiki:Main.CrawfordCurrie
Codebase 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, ~twiki4
SVN Range TWiki-4.1-beta1, Wed, 30 Aug 2006, build 11391
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11444 11573
TargetRelease minor
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch Render_pm.patch r1 manage 1.0 K 2006-09-20 - 09:07 UnknownUser  
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r16 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback