Edit Topic Tree Structure

Since I make extensive use of TreePlugin, to create a "TREEVIEW" or table of contents of a web, I find that I am often reparenting topic pages. (Especially in cases such as EmbedTopicPlugin, which does not create a default parent.)

Changing the parent meta info of a page on page at a time basis is annoying.

It would be nice to have a plugin or tool that allowed the parent/child structure of a web to be edited all at once.

E.g. create a list of pages... using WebTopicList, or TreePlugin.

Edit it as if it is a list. The parent of a page is the page dominates. E.g.

Originally

• Page1
• Page2
• Page2

Edit the list to

• Page1
  • Page2
  • Page3

and have Page1 become the parent for Page2 and Page3

Related: this same tool could be used to create an explicit ordering of child pages

-- AndyGlew - 18 Mar 2006

Discussion leading to first code

Preliminary working Reparenting using TREEVIEW

Finally, I have a reasonably working reparenting mechanism.

I did not need to create a new plugin (although that will eventually be nice). I just passed arguments to TreePlugin (although I had to fix a bug).

Here's the invocation:

%TREEVIEW{formatting="outline" format="$outnum $topic <form name=\"reparent$_outnum\" action=\"%SCRIPTURLPATH{"save"}%/%WEB%/$topic\">   <select name=\"topicparent\" size=\"1\">  <option value=\"none\">none (remove topic parent)</option> %TOPICLIST{"<option value='$name'>$name</option>" separator=" "}%   <INPUT TYPE=\"button\" VALUE=\"Reparent\" ONCLICK=\"document.reparent$_outnum.submit();window.location='https://twiki.pdx.intel.com/archfut/bin/view/$web/TestPage'\"> </form> <br>"}%

Here's an attached screenshot: Sorry, I accidentally loaded a .BMP screenshot, loaded a .GIF a minute later, but apparently am not allowed to delete the first.

• TreeViewReparenting.bmp: Screenshot of TreePlugin used with a form to create a reparenting widget

• Screenshot of TreePlugin used with a form to create a reparenting widget:
  TreePlugin used with a form to create a reparenting widget" width="700" height="800" />

TreePlugin changes

It was necessary to fix a problem with TreePlugin. Ironically, one that I introduced many years ago... the original author of TreePlugin seems no longer to be maintaining it, and I am one of the biggest users.

Anyway, TreePlugin originally did not place [[double brackets]] around topic links. which worked fine for WikiWords, but failed for non-!WikiWord page names. I hacked TreePlugin to add [[double brackets]].

It was this linking that caused the quoting problem when I first tried to add the reparenting form to a TREEVIEW format.

I modified TreePlugin to add [[double brackets]] a bit more carefully. I probably still have it wrong - indeed, some of my old tests of non-!WikiWord pages are failing - but I will post what I have done now because I may not have time to work on it for a while. I hope to get a proper fix soon (although I may be working on other tree oriented tools).

I found it convenient to create a new TreePlugin format variable, $_outnum - $outnum with underscores - that I could use to create Javascript compliant unique names.

• diffs: diffs of TreePlugin changes used to make the reparenter work

• FormatOutlineNodeFormatter.pm: The entire FormatOutlineNodeFormatter.pm

-- AndyGlew - 25 Mar 2006

Shortcomings

This TreePlugin/format/form reparenting approach has several shortcomings:

• reparenting is done one at a time - you select the parent, hit the reparent button, then wait while the tree is recalculated.
  • it would be nice to edit the list, and then make multiple changes all at once

• there seems to be a "stray" form at the top of the TREEVIEW. I have not been able to eliminate it.

• I have not been able to select the current parent as default - since the Meta query applies to the local page only.

Nevertheless, it is useful enough for now.

Also, TreePlugin continues to have problems with non-!Wikiword pages.

More Discussion

I still want the global edit, rather than the pull down approach.

Putting the reparent form in the left bar doesn't seem to work - it reparents WebLeftBar, not the current page.

I tried to put this into a TWikiVariable - but again had quoting issues.

-- AndyGlew - 25 Mar 2006

I removed the "Here's what it looks like, if TreePlugin is installed" part above since the page stopped rendering at that point (using FF 1.0), and since the Plugin is not installed on WTiki.org.

-- PeterThoeny - 25 Mar 2006

The form requires a unique name for every instance. After playing around with _outnum, I have just decided to have a monotonically incrementing global.

-- AndyGlew - 26 Mar 2006

Residual flakiness - I am beginning to think that I need to wait for completion of the submit before the regeneration of the tree.

<UL ... I hacked the JavaScript to include a delay after the submit of the save comand that effects the reparent, before changing the view back to the current document. Things got much more reliable. Unfortunately, this means that the solution is flakey - what happens if the server is really slow? I either need to find a way to wait untol the save command that reparents has completed --- or I want the save command to be able to redirect back to where I started. The former will be useful for multiple reparents. (Hmm, how can I dispatch them in parallel?) -- AndyGlew - 26 Mar 2006

I hacked TreePlugin to remove the spurious first entry.

-- AndyGlew - 26 Mar 2006

Generalizing TopicTrees

Rather than continuing on to make EditTopicTreeStructure more convenient - changing several at a time, rather than one at a time as the stuff above does - I am increasingly thinking about attacking the problem in a different way, described in Generalizing TopicTrees.

-- AndyGlew - 27 Mar 2006

Maybe you could pass another parameter to save.cgi, say background=on, that would be interpreted by Save::savemulti() to mean "Do not redirect after the save operation"?

The following code change in Save::savemulti() seems to be all that is needed:

***************
*** 190,192 ****
--- 190,193 ----
    my $redirecturl = TWiki::getViewUrl( TWiki::Store::normalizeWebTopicName($webName, $topic));
  
+   my $background = lc($query->param( 'background' ));
    my $saveaction = lc($query->param( 'action' ));
***************
*** 210,214 ****
    # save called by preview
    if ( _save( $webName, $topic, $userName, $query )) {
!     TWiki::redirect( $query, $redirecturl );
    }
  }
--- 211,217 ----
    # save called by preview
    if ( _save( $webName, $topic, $userName, $query )) {
!     unless ($background) {
!       TWiki::redirect( $query, $redirecturl );
!     }
    }
  }

Then you could find some way (reparent.cgi?) of cycling through all the changes that were made in the topic form and refreshing the page.

-- PankajPant - 30 Mar 2006

So far I am happy with my own day of using TopicTree... I hope to rope y'all into trying that approach.

-- AndyGlew - 31 Mar 2006

See DynamicReparenting for discussion on a much more user friendly way to accomplish this (only a prototype at present).

-- PankajPant - 07 Aug 2006

Here is the invocation we used to get the topic to save and have the Treeview page reload:

<iframe name="Save" style="display:none">
</iframe>

%TREEVIEW{formatting="outline" format="$outnum $topic <form name=\"reparent$_outnum\" target=\"Save\" action=\"%SCRIPTURLPATH{"save"}%/%WEB%/$topic\">   <select name=\"topicparent\" size=\"1\">  <option value=\"none\">none (remove topic parent)</option> %TOPICLIST{"<option value='$name'>$name</option>" separator=" "}%   <input type=\"button\" value=\"Reparent\" onclick=\"document.reparent$_outnum.submit();var t=setTimeout('window.location=\'%SCRIPTURL{"view"}%/%WEB%/%TOPIC%\'',1500)\" /> </form> <br />"}%

-- ShadTodd - 23 Feb 2007

Thanks Shad for sharing this. I fixed the text for proper XHTML; also, instead of a hard coded domain you can simply write %SCRIPTURL{view}% to get the full view URL, including protocol and domain.

-- PeterThoeny - 24 Feb 2007