• 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.
There is a unit test test_url_parameters in HierarchicalWebTests.pm which fails, and I assume it fails since r11771.

With the creation of Subwebs in TWiki4 it had been possible to create a subweb, say Web/SubWeb. Links to subwebs like [![Web.SubWeb]] have pointed to Web.SubWeb.WebHome, as well as invocations like bin/view?topic=Web.SubWeb, unless a topic named SubWeb existed in Web.

This feature has gone with r11771, committed as a fix to Item2998.

Should the testcase be changed/removed or should the code be fixed?

-- HJ

The code should be fixed. This was the subject of considerable discussion in Codev, IIRC.

-- CC

What about performance? A topic exist check can be expensive in a large web.

I do not recall a discussion on [[Web.Something]] pointing to a subweb's WebHome vs a plain web.topic link. I believe, the discussion was about the Web. and Web.SubWeb. (with trailing dot) and label shown with Web.WebHome links (same web vs. other web.)

The documented way to link/jump to another web or to create another web is the Other/SubWeb. (with dot) or Other/SubWeb.SomeThing notation. See GoBox.

-- PTh

Since the specification seems to be unclear (and I failed to find a Codev topic) I'm setting this to "New". PTh is correct in that a trailing dot or slash will make things work, but I think that 4.0 did it without that.

Regarding performance: The topic exist check is made anyway. If a topic [[Web.SubWeb]] exists, it should be shown - but if not, then displaying an existing [[Web/SubWeb.WebHome]] might be preferable to offering creation of [[Web.SubWeb]]. The performance penalty would only happen in the fallback path, halfway to oops.

-- HJ

A topic exist check can be expensive in a large web - odd. Do you have data to back that up? AFAIK a topic exist check is a if (-f $file) in RcsFile.pm. I can't see how that would be particularly slow in a large web....

Yes, 4.0 did without that. I took quite a while getting that testcase right precisely so it would fail if anything changed, so I regard the testcase as the ultimate specification (much more reliable than memory, or even Codev topics).

CC

The longer I think about it, the more I believe that the test case should be changed. Peter made a good point, which I'll expand a bit:

  1. Without decoration:
    1. [[TWiki]] = TWiki links to Bugs.TWiki, a topic TWiki in the Bugs web. Similar to the GoBox, squabbed links know about a "current" web.
    2. %SCRIPTURL{view}%?topic=TWiki = http://svn.twiki.org/do/view?topic=TWiki links to a topic TWiki in the Main web.
    3. %SCRIPTURL{view}%/TWiki = http://svn.twiki.org/do/view/TWiki links to TWiki.
  2. With a dot (a slash makes no difference) decoration:
    1. [[TWiki.]] = TWiki. links to TWiki.
    2. %SCRIPTURL{view}%?topic=TWiki. = http://svn.twiki.org/do/view?topic=TWiki. links to TWiki.
    3. %SCRIPTURL{view}%/TWiki. = http://svn.twiki.org/do/view/TWiki. links to TWiki.

So basically, without a trailing dot, TWiki does not behave in a consistent manner at all, whereas with a trailing dot, everything works fine.

I do not claim that we must preserve the same inconsistency when considering hierarchical webs. But the use in a %SCRIPTURL{...}% construct, both as a path and a topic query parameter, needs another dimension of consistency: There isn't just view, we also have edit, save, and attach. If you edit or save a Web/SubWeb, then it needs to be the topic SubWeb, regardless of whether a subweb with the same name exists. That, basically, was the point of Item2998.

There is only one case where a bare web name is implicitly augmented with /WebHome: 1.3, where the web name is used as URL path. If used as a query parameter, a bare web name is not interpreted as a web, but as a topic name.

I suggest to take the behaviour of non-hierarchical webs as a base for the specification. We have to treat view/Web in a url path as the only exception from the GoBox rule, more or less justified because there is no "null" web and Web can never be a topic (though that would be an interesting concept wink ).

-- HJ

I crafted the testcase by sitting down with a Cairo install and a TWiki 4 install, and working through all the cases where Cairo behaviour wasn't broken, writing tests that ensure TWiki 4 behaved consistently.

There are three approaches to this problem:

  1. Accept that the <= TWiki 3 approach is broken for hierarchical subwebs, but make it work if subwebs are disabled. This will result in Twiki-4 behaving differently depending on whether subwebs are enabled or disabled.
  2. Accept that the <= TWiki 3 approach is broken for hierarchical subwebs, and change the specification so that the behaviour is consistent whether subwebs are on or off. This may of course break existing content.
  3. Enforce the <= TWiki 3 specification, this is the current state.

FWIW I consider 1 to be unacceptable.

CC

I do not understand case 2: AFAIK, TWiki 3 did not support hierarchical subwebs. That is, we can define a spec that is consistent and makes sense for hierarchical subwebs. Personally I find it confusing to type Web/SomeThing in the go box and up in Web/SomeThing.WebHome.

-- PTh

To help you redefine the behaviour consistently, here are the relevant testcases that reflect Cairo behaviour:

  1. [[SubWeb]] in TestWeb.AnyTopic, no top level web SubWeb, no subweb TestWeb.SubWeb, no topic TestWeb.SubWeb
    • link to create topic TestWeb.SubWeb with TestWeb.AnyTopic as the parent
    • example: [[SubWeb]] - SubWeb
  2. [[SubWeb]] in TestWeb.AnyTopic, no top level web SubWeb, no subweb TestWeb.SubWeb, topic TestWeb.SubWeb exists
  3. [[SubWeb]] in TestWeb.AnyTopic, top level web SubWeb exists, no subweb TestWeb.SubWeb, no topic TestWeb.SubWeb
    • link to create topic TestWeb.SubWeb with TestWeb.AnyTopic as the parent
    • [[LitterTray]] - LitterTray
  4. [[SubWeb.]] in TestWeb.AnyTopic, no top level web SubWeb, no subweb TestWeb.SubWeb, no topic TestWeb.SubWeb
    • TWiki3 behaviour: link to create topic SubWeb.AnyTopic with TestWeb.AnyTopic as the parent
    • TWiki4 behaviour: link to create topic SubWeb.WebHome with TestWeb.AnyTopic as the parent
    • example: [[SubWeb.]] - SubWeb.
  5. [[SubWeb.]] in TestWeb.AnyTopic, no top level web SubWeb, no subweb TestWeb.SubWeb, topic TestWeb.SubWeb exists
    • TWiki3 behaviour: link to create topic SubWeb.AnyTopic with TestWeb.AnyTopic as the parent
    • TWiki4 behaviour: link to create topic SubWeb.WebHome with TestWeb.AnyTopic as the parent
    • example: [[AllOutStandingItems.]] - AllOutStandingItems.
  6. [[SubWeb.]] in TestWeb.AnyTopic, top level web SubWeb exists, no subweb TestWeb.SubWeb, no topic TestWeb.SubWeb
    • TWiki3 behaviour: link to create topic SubWeb.AnyTopic with TestWeb.AnyTopic as the parent
    • TWiki4 behaviour: link to SubWeb.WebHome with TestWeb.AnyTopic as the parent
    • [[LitterTray.]] - LitterTray.

I extended this base set for hierarchical subwebs with:

  1. [[SubWeb]] in TestWeb.AnyTopic, no top level web SubWeb, sub web TestWeb.SubWeb exists, topic TestWeb.SubWeb exists
    • link to topic TestWeb.SubWeb
  2. [[SubWeb]] in TestWeb.AnyTopic, no top level web SubWeb, sub web TestWeb.SubWeb exists, no topic TestWeb.SubWeb
    • link to TestWeb.SubWeb.WebHome
      • I believe this behaviour is not intuitive and not consistent, it should result in a link to create TestWeb.SubWeb topic. -- PTh

I have not defined tests for the for the parallel cases to the two above trailing dot cases, or where a top level SubWeb exists.

These tests reflect the behaviour Peter Nixon originally coded, after I had corrected it for Cairo compatibility.

CC

I fixed the topic name (in red) to reflect the actual behaviour and current spec -- PTh

As I said at the top, these testcases reflect Cairo behaviour, as per my 200409 install. By this definition current behaviour is wrong (if you assume Cairo as the spec). I retained your notes on TWiki4 behaviour, and restored the TWiki3 notes as well.

If we accept the paradigm that a trailing dot/slash is required to refer to a WebHome, and that in all other cases the link is to a topic, existant or non-existant, then that makes perfect sense to me. However this is not Cairo behaviour, which is why I noted in case 2 above that it implies a spec change.

It is very difficult to come up with a set of tests that are consistent with what has gone before. The trailing dot potentially disambiguates subwebs from topics, yes, but it doesn't disambiguate top level versus sub webs. For example, let's say I refer to [[LitterTray.]]. Does that refer to the top level web LitterTray, or to the subweb LitterTray?

Peter tried to layer the subweb hierarchy over the existing addressing scheme in the simplest way possible. Unfortunately he didn't think through all the implications. Remember that webs are now like directories, so you really need a way to refer to a topic at an arbitrary hierarchical level, possibly specified relative to the current web. You also need a way to refer to a web as an entity, also using a hierarchical path specifier. In the current scheme(s) [[SubWeb]] refers to a top level web, so you have already lost the opportunity to use it in the conventional way i.e to refer only to topic or subweb at the current hierarchical level. Further, because topics may be named the same as subwebs, you have an instant mental confusion as to whether [[WebHome]] refers to the topic WebHome in the current web, or the topic WebHome in the subweb WebHome, or the top level web WebHome. Using existance tests to resolve these cases is, from a user perspective, complex and arbitrary.

Whatever you decide, I suggest that test cases such as those described above gives you an unambiguous way to specify the rules. I believe these are the requirements (my prioritisation):

  1. Must be able to refer to a topic in the current web or any subweb below it
  2. Must be able to refer to a topic in a named top-level web or any subweb below it
  3. Should be able to refer to a topic in the parent web or any web above it
  4. Could be able to refer to the WebHome in any subweb below the current web
  5. Could be able to refer to the WebHome in a named top-level web or any subweb below it

Personally I favour totally abandoning links to WebHome topics. I never use them myself, as I find them very confusing.

CC

We discussed this at TWiki:Codev/EdinburghReleaseMeeting2006x12x11 with no strong opinions one way or the other:

[14:27] HaraldJoerg: What about the "discussion" bug 3243?  
[14:27] HaraldJoerg: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3243
[14:27] HaraldJoerg: Discuss between PeterThoeny and Crawford?
[14:27] PeterThoeny: yes, i think this one needs some brain cycles by the community
[14:28] ArthurClemens: anything this confusing should be made simple
[14:28] ArthurClemens: that is: no special treatment, no edge cases
[14:28] PeterThoeny: i agree in this case
[14:29] Lavr: One thing must be clear. Cairo did not have subwebs. If a subweb has same name as a topic then there is no Cairo spec of how to handle that.
[14:29] PeterThoeny: cairo had a bug, it was treating a "web." link differently in the go box and a square bracket link
[14:29] PeterThoeny: it would be nice to have crawford here
[14:30] HaraldJoerg: That's why I doubt there's much point in discussing it here
[14:30] Lavr: I have read the topic and I do not have any religious oppinion about it. I will be happy if those that discuss agree on something.
[14:30] HaraldJoerg: I've brought it up only because unit tests break, I never used hierarchical webs myself
[14:30] PeterThoeny: i think crawford's point is that a [[Web.]] link in a FooBar topic in cairo points to a Web.FooBar topic, and in Dakar it points to Web.WebHome
[14:30] HaraldJoerg: Does *anyone* at our meeting use hierarchical webs?
[14:31] Lynnwood: yes - i do quite a bit
[14:31] PeterThoeny: the cairo spec is a bug imho (and inconsistent with the go box behaviour)
[14:31] Lavr: I have one department that have played with it. But not in a serious way.
[14:31] PeterThoeny: dakar does it right
[14:31] Lavr: I doubt many Cairo users have written [[Web.]]   That is too special a case.
[14:32] PeterThoeny: i never use heararchical webs, they introduce too much complexity
[14:32] HaraldJoerg: Crawford also pointed out that, if you are in Foo.SomeTopic, [[Web.]] could be either [[Foo.Web.WebHome]] or [[Web.WebHome]]
[14:32] PeterThoeny: yes, that is the question where to start looking for hiearchical webs
[14:32] HaraldJoerg: Sort of relative vs. absolute links when using hierarchical webs
[14:32] PeterThoeny: at current location down, or from root
[14:33] PeterThoeny: this was an n/a for cairo
[14:33] PeterThoeny: so it can be defined in an intuitive way for the majority of users
[14:33] HaraldJoerg: Yep. Without hierarchical webs, a topic with '.' is an "absolute" link, without '.' it is relative to the current web
[14:34] Lavr: That would also be my intuitive way of thinking.
[14:34] PeterThoeny: harald, you brought the topic up initially with the question if the recent code cahnge should be changed or the testcase
[14:35] PeterThoeny: i suggest to fix the testcase
[14:35] HaraldJoerg: That would be the pretty easy fix - if Crawford agrees
[14:36] PeterThoeny: ok, let me add a note accordingly to the bug item topic, and let's see if crawford agrees

So, the consensus is to make this intuitive and to keep impact low for the 4.1 release. I suggest to keep the current code and to fix the testcases.

-- PTh

Test cases are important and good etc etc but not a release blocker so I down grade to normal.

And I have seen no recent actions on test cases so I also change to new. Too many bug items are in Actioning too long.

KJL

Please don't do that; "new" means something has not been analysed; we should be aiming to move bugs out of "New" and into "Actioning", not the reverse. A bug should remain in "Actioning" until it is fixed (unless of course new information prompts a state change).

CC

So now that we have all agreed in twiki-dev that New means "noone is working on it" and it does not occur to me that CC is working on this one I flip it back to New indicating that anyone is free to pick it up.

If you want to work on it CC be so very welcome to flip it to actioning again.

KJL

Reverting to Actioning. Please read http://twiki.org/cgi-bin/view/Codev/Post4Point1BugDBImprovements.

CC


I've fixed the test case and am closing this bug now. I've deliberately left it open to allow review of the changed spec, but not to play Actioning/New pingpong.

HJ


FWIW, you guys really pulled the rug out from under us at the University of Minnesota. We have 190k+ of page hits on our TWiki installation each week, and it has been quite unpleasant to have subweb linking stop working.

This is especially frustrating since there is no documentation of this change in the release document (there is no recommendation when upgrading to peruse the development web), there is no documentation on how to 'officially' or 'correctly' link to a subweb, to avoid having a change impact.

Equally frustrating is to have CC blame us for not being developers of TWiki to know this is going on. Also, very frustrating is to read the discussion above and not see a reference to address people who might be greatly impacted by this change. The suggestion by CC to do a global replace is shortsighted and without consideration of the problem. A search and replace cannot distinguish between [[*/topic]] and [[*/subweb]], which is very important is [[*/topic/]] will not work.

This type of inconsideration for people using TWiki is not unique to this case, this was also an issue with controlling access with Groups (Bugs/Item2835) change made from T3 to T4, with only a cryptic explanation by CC that is was a security feature fix.

I ask that you consider what impact your changes will have, once you have release a feature for more than a year (people are going to use it, even if not all developers like the feature). I ask that if you do have to make such a change, you have the consideration to make it known in the release notes as a major change. I ask that you provide a way for users that are impacted by large changes to deal with those changes. While this may seem like alot of things to ask for, its par for the course for software development.

Thank you.

-- TWiki:Main.EricHanson

Bug or feature, that is the question. Personally I find that TWiki 4's behaviour of [[Foo/Bar][Foo Bar]] pointing to Foo/Bar.WebHome is a bug. It was never documented as such, and it is not consistent with Cairo. Both, TWiki:TWiki04.GoBox and TWiki:TWiki04.GoBox document that Main. (with dot) specifies a link to the home of the Main web. As a logical extension, Main/Sub. (with dot) specifies a link to the home of a subweb.

TWiki has extensive documentation, but more work needs to be done. I invite all users of TWiki to participate in doc writing. If you feel that something is not well documented please help improve it, or please add a note in the dicussion section of a TWiki:TWiki.DistributionDocument. For example, the WikiWord doc should explicitly document subweb links and Web. (with dot) links.

I also invite users to get involved in the vetting process of new features. The more participation we have, the more stable TWiki gets. See TWiki:Codev.TWikiRelease04x01Process. If inclined please join the customer advocate team.

-- TWiki:Main.PeterThoeny - 18 May 2007

ItemTemplate
Summary Web/SubWeb does no longer point to Web/SubWeb/WebHome
ReportedBy TWiki:Main.HaraldJoerg
Codebase ~twiki4
SVN Range TWiki-4.1, Tue, 28 Nov 2006, build 12081
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 12326
TargetRelease n/a
ReleasedIn

Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2007-05-18 - TWikiUserMapping_PeterThoeny
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback