Tags:
create new tag
view all tags

Avoid Parent Across Webs

Moved from Bugs:Item2294, Moving a topic with a parent to another web leaves its parent in the old web


For example, I wound up with:

CSA > TWiki.TWikiTipsOfTheDay > TWikiTip001

This may be true in 4.0.x as well.


Right..... so what's wrong with that? It seems pretty intuitive to me....

-- CC

I guess I assumed that a topic's parent would always been in the same web. If that's not the case, then this isn't a bug, but it's quite disconcerting to click on the breadcrumb and suddenly be in a different web which may look quite different.

-- ML

It's not the case. The breadcrumb looks ok once you get used to it.

-- CC

I disagree. It breaks the mental navigation model. Don't make me think

The correct fix is to remove the parent if the topics is moved from one web to another.

-- PTh

Quite on the contrary, I've always experienced it as a nasty restriction that I can not (re)parent a topic across webs. Webs are, per technical definition, server-side organisation issues (e.g. with regard to access control), whereas the breadcrumb/parent structure can be driven content-oriented. Example: A topic like TWiki:Codev.TransparentAuthentication would have a "natural" parent in TWiki:TWiki.TWikiUserAuthentication, rather than in TWiki:Codev.WebHome or in "no parent at all".

I concede that the feature to create cross-web breadcrumbs by moving topics is rather coincidental, in the sense of "the current implementation turns out to behave like that". Removing the parent makes the behaviour consistent, but, in my opinion, consistently deficient.

-- TWiki:Main.HaraldJoerg

I have to (mostly) agree with PTh here. There should at least been an option to remove the parent. For me it's not a "Don't make me think" item so much as a) it creates an extra step in authoring to fix up the parent and b) as I said above, it can be disconcerting to click a topic's parent and wind up in a different web that looks quite different.

There's also a bug in patternskin, last I looked, with this. I'll have to investigate a bit before posting a bug report.

-- ML

So, we have two for and two against. Any other inputs?

-- CC

I agree that in 95% of the time it is bad practice to have the breadcrums trail crossing webs. But there is something in Harald's post - f.i. one could imagine that you have a "comments" web where comment topics should link back to a doc topic.

So to make the system not too rigid, but still easier to use than now: can't we add an option on the rename page to optionally choose a new parent?

-- ArthurClemens - 26 May 2006

I'm in the camp that think that in some cases Users should not be concerned about the web they're in.

To make the system flexible, I think that Arthur's proposal is a good one.

-- RafaelAlvarez - 26 May 2006

I would also like to have the choice. I vote for Arthur's proposal.

-- DiabJerius - 26 May 2006

I'm not sure what Arthur's proposal actually is. Which is it, 1 or 2:

  1. On move topic, offer a dropdown to select a new parent. If no new parent is selected, leave the topic with no parent.
  2. On move topic, offer a dropdown to optionally select a new parent. If no new parent is selected, leave the existing parent even if is is in a different web.
Personally I don't have a problem with parenting across webs. After all, you can link across webs, and a parent is just a link.

-- CrawfordCurrie - 28 May 2006

Option 2. 2 dropdowns even: 1 for web and 1 for the topic. The current parent (web, topic) is selected by default.

-- ArthurClemens - 28 May 2006

I like option 2 better.

-- SteffenPoulsen - 28 May 2006

I'd like it to be a user configuration setting, so either option is possible, as I have no philosophical reason to disallow it. However, the UI issues are a bit more complicated than has been discussed:

  1. If the breadcrumb is all in one web, you have Web1 > MommyDearest > PoorChild. If the user clicks on MommyDearest, the breadcrumb becomes Web1 > MommyDearest.
  2. If the breadcrumb crosses webs, you have Web1 > Web2.MommyDearest > PoorChild. If the user clicks on Web2.MommyDearest, the breadcrumb changes to Web2 > MommyDearest, and the grandparent of PoorChild is no longer in it. This is disconcerting.
  3. A dropdown for a move-with-reparenting would have to be done in a second step, since the possible parent topics can't be known until the new web is selected. Therefore the only practical possibilities are:
    • no parent (resulting in the new web being the parent)
    • leave parent as is.

-- MeredithLesly - 28 May 2006

I consider this "feature" a bug that should have been fixed many TWiki generations ago. Parent links across webs break the mental model of Site home > Web web > BaseTopic > Topic > Topic > Child. Or, in other words, they break the mental tree model as seen in TWikiPresentation2006x04x05.

For the comment in other web example, this is a special case. It can be done with prominent links at the top of the page, or with a customized skin that changes the breadcrumb.

I am fine with Arthur's proposal, although it is not KISS.

-- PeterThoeny - 01 Jun 2006

I think that the whole idea of the "breadcrumb", as is, is not very well done. There are two concepts that are being mixed: nav history and "topic path".

But it's two late and I can't think a good description... help?

-- RafaelAlvarez - 01 Jun 2006

I think Arthur pointed this out elsewhere. There are two different things called "breadcrumb":

  • a "home path" (what we call "breadcrumb" here in TWiki)
  • a "navigation history", e.g. the "click-click-click" history to the current page (currently not used in TWiki)

-- PeterThoeny - 01 Jun 2006

Parent across webs also breaks the KISS model. It complicates matters, as can be seen for example in TreePluginDev, StephaneLenclud's comment of 15 Sep 2006. Lets make the "home path" a direct and intuitive path, not a detour. And lets handle the special case as a special case with a customized skin.

-- PeterThoeny - 15 Sep 2006

It is indeed distracting to be sent to another web when using the "home path". TWiki should make it easier to keep the parent property consistent when moving topics across webs for instance.

Yet we should not prohibit cross web parent and maybe one day someone will come up with a nice way to set topic parent from another web so that customized skin can make use of that feature.

However in the default TWiki structure and using the pattern skin it does not bring anything else than confusion to have a parent living in another web. Power users can live with that but your avarage users will just get confused if ever they notice it. So you get users asking themselves "How on earth did I end up in the HR web? I was just looking for something in the Market web!!". As a TWiki administrator I would get ride of cross web parent and try to talk my users in doing the same. As Peter put it "prominent links" makes more sense for cross web relationship.

-- StephaneLenclud - 16 Sep 2006

Have you thought about hieararchical webs? It seems rather obvious that there might be many parent relationships across that type of structure, not?

I think we are making a mountain out of a mole hill here. I cannot quite imagine anybody freaking out over clicking on a parent link and ending up in a different web.

Actually, I don't think that the breadcrumb navigation is used that much...

-- ThomasWeigert - 01 Oct 2006

I am with Thomas here. I think the current breadcrumb is working just the right way. I often use it to navigate back to the parent. And I do not care what web that parent is in. The parent must be a relevant page since it contains a link to the child.

I see a good use in a TWiki application where either a web or subweb is used for many records in a TWiki Application and with links to these from a different web.

If you do not want the breadcrumb to point back to another web then you can control this by changing the parent topic in "more topic actions".

So the current implementation allows the best from all perspectives and I would be sad if it was changed.

-- KennethLavrsen - 01 Oct 2006

Of corse I can fix the parent at any time. But needing to fix the parent every time I move a topic to a different web (to reduce the surprise for users) is not really user friendly. Don't Make Me Think.

-- PeterThoeny - 01 Oct 2006

There seems to be TWO usecases and we may not be talking about the same.

I want to make sure that it is still possible to have a parent in another web.

You talk about what happens when you MOVE a topic to another web. I am OK with having the parent reset when you move a topic to another web. But I would not want to loose the ability have CREATE topics with parent in another web.

-- KennethLavrsen - 01 Oct 2006

Kenneth, removing the parent when moving a topic to another web was my point all along, as I stated in the beginning.

Thomas: The topic hierarchy fits nicely into the web hierarchy, as you can see on the left graph that shows a proper "path towards home" in red. Now, consider a topic that has been moved to a different web with the parent left in the old web. The "path towards home" is now broken as you can see in the graph to the right:

broken_path.gif

I think we should not prevent TWiki applications from creating broken "path towards home", but we should fix the bug that creates a broken path when moving a topic across webs.

-- PeterThoeny - 01 Oct 2006

I too am experiencing this problem and would be very grateful for a fix to allow me to "fix" the incorrect breadcrumb that shows the wrong old web parent.

-- JohnCalvert - 30 Oct 2006

What about implementing a "move topic tree" function in the "more topic actions"? I guess that's a key missing piece and a must have functionality for our structured wiki. The fancy javascript UI can wait.

-- StephaneLenclud - 07 Dec 2006

There are already a "Rename/move topic..." links in the "More" screen. Possibly better to to have a "Move children too" checkbox in the rename confirm screen. Better to discuss this in a new Codev topic.

-- PeterThoeny - 07 Dec 2006

Parenting across webs may get very confusing. But it may be done - try to set it from the command line. But a number of things are missing:

  • When choosing a parent in More, we could add a dropdown with available webs - the current web selected - showing the list of web topics in the select box.
  • The breadcrumb has the current web's webhome hardcoded as level 1 topic (level 0 is TWiki).
  • My HierarchicalNavigation parent search breaks on it. Possibly other searches as well.
    • $parent is expanded to a link when parent is web.topic

-- ArthurClemens - 08 Dec 2006

The "Move children too" checkbox sounds good to me.

-- StephaneLenclud - 08 Dec 2006

But wouldn't you need to select a web as well?

-- ArthurClemens - 08 Dec 2006

(I moved above posts from DynamicReparenting)

-- PeterThoeny - 08 Dec 2006

Yes you do select the Web you are moving your topic to. The use case goes like that:

  • Do More topic actions
  • Do Rename/move topic...
  • Select the web you are moving your topic to
  • Tick the new Move children too check box
  • Click the Rename/Move button
  • You are done! You've moved an entire tree to another Web

Since we want to avoid parent across Webs I don't think we want to offer users the possibility to select a parent from another Web.

-- StephaneLenclud - 09 Dec 2006

How do we go about implementing that feature? Should it be a new parameter to the rename script? Something like movechildren. rename could then do a search for children and call itself recursively on each of them. Other thing to consider:

  • Shall we just remove the parent topic property when moving to another Web? Thus preventing parent across Webs.
  • Shall we add a newparent parameter to rename in order to implement the Move children too feature and other reparenting while moving behaviour?

-- StephaneLenclud - 09 Dec 2006

Let's fix this once and for all: Never link across webs in a breadcrumb. See related post, Support.SID-01208.

-- PeterThoeny - 2011-06-21

As for spec I think we should go for this:

  • A parent can only be set for a topic in the same web.
  • When moving/renaming a topic across webs, the parent meta data should be removed (unless multiple topics are moved where you want to preserve the parent-child relationship).
  • Legacy data: Existing topics may have META:PARENT of Otherweb.TopicName. The meta datra should be ignored, e.g. the breadcrumb stops here if Web.Topic parent is encountered.

-- PeterThoeny - 2011-06-21

I suggest to turn this brainstorming idea into a feature proposal.

-- PeterThoeny - 2011-06-21

Is there a way to rename multiple Topics at the same time ?

-- AlinGramescu - 2011-11-03

Please do not cross-post the same question in many topics. Please open a support question in the Support web.

-- PeterThoeny - 2011-11-03

Edit | Attach | Watch | Print version | History: r27 < r26 < r25 < r24 < r23 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r27 - 2011-11-03 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.