Planning:Treeview skin:Feedback - clc-wiki

The treeview skin is now available as a beta and is the default skin for this wiki. If you encounter bugs, or you have feedback or comments that you'd like to leave, they'd be welcome on this page. Anonymous edits are no longer enabled on this page due to excessive spamming. For those who would rather not create an account to edit this page, you may contact the skin's author directly.

Bug reports

Cyrillic encoding problem

Doesn't work with Cyrillic, encoding UTF-8. Upper nodes looks perfect, but when expand you can see just "Branch data missing.Try a full page reload." in IE, " * Containing node no longer exists.Resync treeview." in Mozilla and Opera. Any suggestions?

Let's troubleshoot a little. Firstly, do you have any evidence that Cyrillic encoded in UTF-8 is causing these problems (e.g. "it works OK with English encoded as UTF-8")? Secondly, do you see the branch when you click on the full page reload link? Finally, does the node whose expand button you clicked still appear when you click on the resync treeview link? --Netocrat 00:03, 22 March 2007 (UTC)

Here is some more information and another idea. I did not consider character set or character encoding issues whilst designing the skin, so I suppose that this sort of problem is to be expected. If you want to dig a little deeper into what's going on, you could try this:

find in skins/treeview.js the line that begins "req.open(" - it is line number 1162.
immediately prior to this line, add a line that reads: alert(xmlurl);
save the file then point your browser at your wiki and load an arbitrary page
click on an expand button and you should get a pop-up displaying the link that the javascript is about to download the xhtml from
copy this link (probably you will have to do this by typing it out manually)
at a shell prompt (I'm assuming that you're running a Unix variant and have the lynx text browser installed) run: lynx --dump 'replace_this_with_the_copied_link'
check the output for well-formedness of the xml. You could also share it by posting it to this page or emailing it to me. --Netocrat 09:29, 22 March 2007 (UTC)

1. Thanks for your help. English works fine. Here is the picture how it looks with cyrillic:

tree (don't know how to upload images to your server, and I'm not really familiar with wiki syntax)

2. Full page reload doesn't help.

3. Yes. When I click resync expand button appear and I can see child node, this doens't work in IE(no resync link here).

4. No Unix, just Windows.

Here is what I've got:

Opera:

XMLURL: /wiki/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Hierarchy&base=%2Fwiki%2Findex.php&effurl=%2Fwiki%2Findex.php%2FMain_Page&expnodeids=_ýýýýýýýýýý__1&skiplinkstaterebuild=1&tvstate=e__ýýýýýýýýýý__1

XML:

<div>

</form>

</div>

IE:

XMLURL: /wiki/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Hierarchy&effurl=%2Fwiki%2Findex.php%3Ftitle%3DMediaWiki%3ATreeview%26action%3Dedit&expnodeids=_testnode__1,_𢰵񃱰?𳱰񃰟_1&skiplinkstaterebuild=1&tvstate=e__content__1,e__11__2,e__testnode__1,e__𢰵񃱰?𳱰񃰟_1

XML:

<div>

<ul>

<a href="/wiki/index.php?title=Test_Subnode&action=edit" title="Test Subnode" class="new">Test Subnode</a>

</span>

</li>

</ul>

</div>

</div>

</form>

</div>

Mozilla:

XMLURL: /wiki/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Hierarchy&effttl=%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0&effurl=%2Fwiki%2Findex.php%2F%25D0%2597%25D0%25B0%25D0%25B3%25D0%25BB%25D0%25B0%25D0%25B2%25D0%25BD%25D0%25B0%25D1%258F_%25D1%2581%25D1%2582%25D1%2580%25D0%25B0%25D0%25BD%25D0%25B8%25D1%2586%25D0%25B0&expnodeids=_%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD__1&skiplinkstaterebuild=1&tvstate=e__%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD__1

XML:

<div>

</div>

</form>

</div>

--Loki 26 March 2007

OK, try this fix. To extensions/Hierarchy/UtilityFunctions.php insert at line 132 - i.e. immediately after the line that reads $ret = ''; within filter_non_alnum() - the following code: $str = urlencode($str);. Then rebuild the treeview (e.g. by navigating to the url mediawiki/index.php?title=MediaWiki:Treeview&action=rebuildtreeview when logged in as a user with the 'rebuildtreeview' right) after first making sure that the $wgStoreTreeviewNodeIdsInDB setting is false (which it is by default so if you don't know what I'm talking about then just ignore it). Now try expanding nodes and if it works... well, please let me know and we can close the case. If it doesn't work, then please answer these questions: were the ? symbols above already in the xml output that you pasted or were they translated from some other characters when you saved this page in MediaWiki? If some other characters, then what were those original characters?

--Netocrat 04:47, 27 March 2007 (BST)

Wow! It works! Everything's ok. Thank you very much.

--Loki 09:38, 27 March 2007 (BST)

Link problem in IE

I found one strange bug. It happens only in IE. So some(only some) of the tree leafs have strange links. For example, link should be "/wiki/index.php/%D0%A6%D0%B5%D0%BB%D1%8C_%D1%80%D0%B0%D1%81%D1%87%D0%B5%D1%82%D0%B0" but it is "/wiki/index.php/Ð¦ÐµÐ»Ñ_ÑÐ°ÑÑÐµÑÐ°" And, when I take a look inside html code of that page, the link was ok, it was "/wiki/index.php/%D0%A6%D0%B5%D0%BB%D1%8C_%D1%80%D0%B0%D1%81%D1%87%D0%B5%D1%82%D0%B0" That happens only in IE, Mozilla is ok, Opera seems to be ok also.

Any suggestions? Thanks.

--Loki 16:04, 23 April 2007 (BST)

By "it is" do you mean the appearance of the url in the statusbar when you hover over the link and/or the appearance of the url in the address bar when you actually click on the link? Please describe the page that appears in IE when you click on this link, especially which article title appears as the main heading. --Netocrat 18:00, 23 April 2007 (BST)

1. In the beginning everything is ok. I can expand tree.

2. I click first time one of the leafs and get my article.

3. After that some of the links point to the wrong place.

4. I clicked wrong link, I've got that page doesn't exist. I can see the tree, can see right links, but in html code, there are no tree links at all, only the first one, the head. Looks like all other links was taken from the cache or something like that.

Here is some screenshots, hope they'll help.

This is what I see after first click and before second click.

And here is what I've got after I've clicked second time.

--Loki 13:47, 24 April 2007 (BST)

Loki, mate, I'm struggling to understand what might be the problem. All that I can think of is to request more information from you although I can't promise that it will provoke any realisations in me. In the second image you write that the "link is now OK". By this do you mean that when click on it that the page loads without error? Also, which other browsers than IE have you tested and found to work as expected? --Netocrat 14:41, 24 April 2007 (BST)

1. Yes, on the second image links is ok, and I click them and get right page.

2. I've tested on IE, Mozilla and Opera. In Mozilla and Opera everything works fine!

I guess, that this is IE problem with UTF-8 encoding.

--Loki 10:49, 25 April 2007 (BST)

That seems possible. Perhaps you could search the web to see if there's any information about IE and UTF-8 encoding problems. At this point I don't have any suggestions apart from that. --Netocrat 21:14, 25 April 2007 (BST)

Are you storing any data for leafs in a cache or something like that?

I changed encoding in IE to something different from UTF-8 and I've got this:

encoding

--Loki 16:08, 26 April 2007 (BST)

Yes, the leaf data is stored in whatever cache you have set up, if any. Often this is memcached - is that what you're using?

I gather that you expected something different, so what did you expect to get when you changed the encoding? --Netocrat 04:33, 29 April 2007 (BST)

I expected text with wrong encoding, like it is on top of the page, like the whole page, except the left-bottom part, where text is still in UTF-8. I'm using eAccelerator for caching. --Loki 10:22, 30 April 2007 (BST)

I don't know what you mean by "except the left-bottom part, where text is still in UTF-8". The left-bottom part of your encoding picture seems to me to have the same encoding as the rest of the page. --Netocrat 07:57, 1 May 2007 (BST)

Troubles with installation / mediawiki 1.9.3 / Diagnose empty or invalid hierarchy

Hello,

nice idea with the treeview structure ! I tried to set up it on my mediawiki. I'm using mediawiki, Release 1.9.3 (operating system: windows). For improving performance of mediawiki I'am using eAccelerator too.

## Shared memory settings
$wgMainCacheType = CACHE_ACCEL;
$wgMemCachedServers = array();

//...

# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$configdate = gmdate( 'YmdHis', @filemtime( __FILE__ ) );
$wgCacheEpoch = max( $wgCacheEpoch, $configdate );


//....

$wgUseFileCache = true; // => Use Squid or MediaWiki's native file cache ($wgUseFileCache = true) to cache whole pages 
$wgCachePages = true;
#$wgAntiLockFlags = ALF_NO_LINK_LOCK | ALF_NO_BLOCK_LOCK;
$wgUseEAccelShm = true;
$wgDisableCounters = true;

I considered the installing instructions in [1].

Following settings have been added at the end of my LocalSettings.php file:

include_once('extensions/Hierarchy/SpecialHierarchy.php');

# Customise these permissions as required; they are described beside the
# $wgGroupPermissions entry under "Variables and settings" in README.Treeview.
$wgGroupPermissions['*']['rebuildtreeview'    ] = true;
$wgGroupPermissions['*']['parsetreeview'      ] = true;
$wgGroupPermissions['*']['treeviewcachestatus'] = true;
# Optionally set Treeview as the default skin ($wgDefaultSkin is probably
# already set elsewhere in the file).
$wgDefaultSkin = 'treeview';
# Not required if $wgCachePages and $wgUseFileCache are both false.
# path/to/file is a file that the web-server has read/write permission on.
$wgCacheEpochTouchFile = 'C:/temp/mediawiki/treeview/treeview_CacheEpochTouchFile.txt';
# Uncomment this if $wgUseDatabaseMessages is false but an editable
# configuration at the default configuration message page is required.  The
# default configuration is the 'Treeview' message in the file
# extensions/Hierarchy/languages/$wgLanguageCode.php.
$wgHierarchyPage = 'MediaWiki:Treeview';

This didn't work. After that, I created the table:

#'mw_' is the prefix of all tables used by mediawiki = $wgDBprefix
CREATE TABLE mw_treeview_used_nodeids (
	tv_nodeid varchar(32) NOT NULL PRIMARY KEY,
	tv_visiblecontext varchar(1024) NOT NULL
) TYPE=InnoDB;

Then the setting $wgStoreTreeviewNodeIdsInDB = true; has been added to the LocalSettings file.

The browser still complains about empty or invalid hierarchy. See screenshots:

The click on 'Rebuild treeview' has no affect. This (positive) message appears:

Rebuild treeview
Successful treeview rebuild
Success: rebuilt the treeview, saved it to cache, and then retrieved it back from the cache.
Cache retrieval result after rebuild-save
Cache hit: a usable hierarchy structure was found with creation timestamp 20070504102549.
Cache retrieval result before rebuild-save
Cache hit: a usable hierarchy structure was found with creation timestamp 20070504102054.
Configuration parse error(s) and/or warning(s)
No errors or warnings.
Configuration text

The table 'mw_treeview_use_nodeids' is empty. There should be stored all nodes and relations between them (articles, categories and so on), right ?

Any suggestions ?

Thanks a lot. --Kati 11:32, 4 May 2007 (BST)

A response

Kati, thank you for your well structured and informative report.

The problem that you are experiencing seems to be largely (but see below) attributable to the bug that I mentioned that I was working on a solution to below in discussion with Potwhale regarding his suggestion "TreeView structure as table of content". I have found a solution, however in the process I have uncovered another bug that I am in the process of solving, so I will not yet release a fixed version (incidentally, I have also implemented Potwhale's suggestion). The problem is that when the 1.9 series of Mediawiki receives a request to translate a message key into a message, it automatically sets the initial character of the message key to lower-case (earlier versions of Mediawiki refrained from modifying the key at all). This means that the 'Treeview' message is now searched for as 'treeview' and is therefore not found, leading to the 'Diagnose empty or invalid hierarchy' message.

Now above I wrote "largely", because this situation does not apply to your configuration (I imagine that originally you had $wgHierarchyPage unset per the default configuration and hence that originally it did apply): you have set the $wgHierarchy variable to a value other than empty, so that the treeview code is not actually looking to translate the 'Treeview' message but is instead requesting the Mediawiki code to pull the specified article out of the database. That specified article is 'Mediawiki:Treeview'. This, as far as I know, should solve your problem, but only if that article is actually saved to the database. Now it seems likely to me that in your case, that article has not yet been saved to the database, given that you are still receiving the empty-treeview diagnostic, and also given that in the 1.9 series of Mediawiki, even when $wgUseDatabaseMessages is true, no message is saved to the database unless/until a user edits and saves that message.

The reason that you are getting a successful rebuild of the treeview is probably that the 'Mediawiki:Treeview' article is unsaved and therefore empty, so that the treeview rebuilds from an empty configuration. The reason that you are still getting a diagnostic is the same: the configuration is empty.

Great, you say to yourself, a lovely deluge of information. But you haven't given me any actual help yet! OK, so here are some options:

Wait a few days until I release a new version that solves this problem
Hunt down the 'Treeview' message in extensions/Hierarchy/languages/en.php and save its contents into the article specified by $wgHierarchy, which as far as I understand you should be able to leave as 'Mediawiki:Treeview'. If my understanding is faulty, then try the main namespace instead e.g. an article titled simply 'Treeview_Config'.

The table 'mw_treeview_use_nodeids' is empty. There should be stored all nodes and relations between them (articles, categories and so on), right ?

It stores the node id used for each visible context, where "visible context" is the node's hierarchy as it appears in the treeview (e.g. "This article:Edit article"). The main reason that this is useful is pretty inconsequential hence I don't recommend that the table be used. Here follows a description of the main reason anyway so that you can decide for yourself. When you include an uncreated article in the treeview (a red-link), the treeview will assign a node id to it (a string of characters) but that node id will not include the Mediawiki-assigned article id, because the article does not yet exist and therefore does not yet have an article id. Usually the node id does include the article id. When $wgStoreTreeviewNodeIdsInDB is true, and when the uncreated article is subsequently created, the treeview code knows not to try to include the article id as part of the node id because it remembers the previous node id that it used. The importance of this is very slight: after you create the new article, if someone else already has a wiki page open showing the red node and if that person tries to expand the red node, then they will be successful (the node id will not have changed); when $wgStoreTreeviewNodeIdsInDB is false, then they will be unsuccessful (the node id will have changed and will not be found) and will have to first reload the page.

Aside: I couldn't access the images that you posted because they were not uploaded to the clc-wiki server (you have provided us with upload links rather than with links to the uploaded - which they seem not to have been - images); however I am confident in my diagnosis without seeing them. --Netocrat 00:55, 5 May 2007 (BST)

The new version - 1.3 beta - linked to at the top of this page should solve your problems. --Netocrat 12:10, 6 May 2007 (BST)

A response

Hi Netocrat, thanks for your prompt feedback ! Unfortunately it is not possible to upload a JPG. I got the message Could not copy file "/tmp/phpaSK1gW" to "/home/comp.lang.c/clc-wiki.net/user/htdocs/mediawiki/images/1/18/treeview_empty_or_invalid_hierarchy.jpg". Currenty I don't have private webspace so that I couldn't upload the images on an another internet server. Anyway, I will try the new version of the skin and give you feedback as soon as possible. Many thanks !

Comments, suggestions and other feedback

TreeView structure as table of content

I am trying to implement Mediawiki as a platform for a flexible but book-like knowledgebase. Is it possible to put the structure generated by TreeView on a seperate page as a table of content? What I would like is to have the same hierarchy as in the sidebar on a seperate wiki page. Great work on the TreeView skin so far, by the way! --Potwhale 10:54, 13 April 2007 (BST)

Currently that's not possible but it's a good idea. I'm thinking that a new tag could be introduced - perhaps <hierarchy></hierarchy> - that would enclose a block of configuration text as at MediaWiki:Treeview. The reason that I think that a separate configuration would be necessary is that you probably wouldn't want the default variable branches (Accounts and This article) showing up on your wiki page. I suppose that another way to avoid them would be to take the default treeview configuration as the base and allow those branches to be pruned. I'll think a little more carefully about it but won't have time to implement this for at least the next few days. --Netocrat 04:06, 14 April 2007 (BST)

Well, I am glad you like the idea. If you don't have time for a full implementation, it would be great if you could just post a version which allows the integration of the tree into a mediawiki page without pruning the default pages. --Potwhale 16:47, 23 April 2007 (BST)

I now know what I want to do and it is simply a matter of implementing it. I hope to have something for you in the next day or so. --Netocrat 18:39, 23 April 2007 (BST)

My hope turned out to be unfounded: I have found a tricky bug that requires a solution first, and I have also been distracted by other interests. This time I will refrain from implying any expectation of a time frame. I have not forgotten your idea though and I still intend to implement it. --Netocrat 04:36, 29 April 2007 (BST)

Ok, I hope you get around the problem. I will check back here occasionally and see if you implemented it. Thanks! --Potwhale 08:30, 2 May 2007 (BST)

I've implemented it in version 1.3 beta, as linked to top-of-page. An extract from the notes that I've added to skins/treeview/help_articles/Help.Treeview_skin.wiki:

To insert the hierarchy into a wiki page, use the
<code><treeview pruneids="id1,id2,..."></treeview></code> syntax,
where the "pruneids" attribute is optional but where specified results in the
branches with matching nodeids (as specified against them in the configuration
message) being pruned.  Typical values for 'id1' and 'id2' are 'accounts' and
'artroot' which represent the dynamic 'Accounts' and 'This article' branches
respectively.

Please let me know how this feature might be enhanced (it currently does not support display of icons). --Netocrat 12:10, 6 May 2007 (BST)

Wow, that was fast. And it works (almost) perfectly! For some reason, I could not get the "pruneids" to work. My current syntax is:
<treeview pruneids = "accounts, artroots"></treeview>
The result still looks like:

Accounts
- some subtrees
This article
- some more subtrees
Main page
- my wiki pages

My MediaWiki:Treeview confugaration is as following:

* tv_nsp_accounts NODE icons=[[Image:users.png]],[[Image:users_plus.png]],[[Image:users_minus.png]] tooltip=tv_ntt_users
*# tv_nsp_logincreate NODE(ifnotloggedin) icons=[[Image:greendoor.png]] tooltip=tv_ntt_logincreate nodeid=acc
*# tv_nsp_accountpage NODE icons=[[Image:user.png]],[[Image:user_plus.png]],[[Image:user_minus.png]] tooltip=tv_ntt_personal
*## tv_nsp_accounttalk NODE(ifloggedin) icons=[[Image:user_talk.png]]
*## tv_nsp_iptalk NODE icons=[[Image:user_talk.png]]
######the rest of the standard configuration file and then my stuff:
* [[Main Page]] NODE
* some more subpoints of my pages
* tv_nsp_help NODE tooltip=tv_ntt_help
** tv_nsp_helpimport IMPORT
** tv_nsp_helpcontentspr PRUNE
* tv_nsp_project NODE tooltip=tv_ntt_project
** tv_nsp_projectimport IMPORT
** tv_nsp_projectaboutpr PRUNE
* tv_nsp_special NODE expanded tooltip=tv_ntt_special
** tv_nsp_commontools NODE expanded
*** tv_nsp_recentchanges NODE
*** tv_nsp_randompage NODE
*** tv_nsp_uploadfile NODE(ifhasright(upload))

I must admit, I never understood the tv_nsp_accounts and similar entries, I just left them there. Anyway, I am using MediaWiki 1.7.1, PHP 5.2.0, MySQL 5.0.32 and TreeView 1.3 beta, obviously. If you know a quick solution to the pruning problem, please let me know.

And a suggestion for a clearer looking hierarchy page would be to start with a larger font size for the highest hierarchies and decrease it for the lower level hierarchies, like:

toplevel
- sublevel 1

Ok, thanks a lot for implementing the TOC-style hierarchy tag! --Potwhale 13:16, 8 May 2007 (BST)

The reason that the pruneids is not working is that I only added most of the node ids in the most recent version of the configuration, and you have based yours off an older one. To get it to work, add to the top-level accounts node the parameter nodeid=accounts and to the two top-level article nodes add the parameter nodeid=artroot. In other words the respective lines should look like this:

* tv_nsp_accounts NODE icons=[[Image:users.png]],[[Image:users_plus.png]],[[Image:users_minus.png]] tooltip=tv_ntt_users nodeid=accounts
# tv_nsp_thisartredir NODE(ifnotisspecialpage ifredirected) selected(never) nomatch icons=[[Image:page.png]],[[Image:page_plus.png]],[[Image:page_minus.png]] tooltip=tv_ntt_thisartredir nodeid=artroot
# tv_nsp_thisarticle NODE(ifnotisspecialpage) selected(never) nomatch icons=[[Image:page.png]],[[Image:page_plus.png]],[[Image:page_minus.png]] tooltip=tv_ntt_thisarticle nodeid=artroot

The tv_nsp_accounts and similar entries are simply message keys (it was designed that way to aid the translation process), so if you look up Mediawiki:tv_nsp_accounts then you will find the actual (English) entry that gets substituted into the configuration at that point.

I will keep in mind your idea for different font sizes - perhaps I will introduce classes that can be styled in css. --Netocrat 11:34, 10 May 2007 (BST)

Works like a breeze now, thank you! --Potwhale 13:13, 11 May 2007 (BST)

When will the treeview skin be publicly released?

I'm customizing mediawiki for use as a knowledgebase and the treeview navigation is a must-have. How about a beta release? :)

I don't know whether Netocrat, the primary developer of the treeview skin, is ready for that, but you can always download a tarball of my complete mediawiki install. See clc-wiki:Config:Wiki. --Flash Gordon 16:55, 5 July 2006 (BST)

There are too many rough edges for a public beta but it's improving. Drop me an email if you'd like a smaller, skin-only "alpha" archive. --Netocrat 02:59, 6 July 2006 (BST)

Comparing TreeView skin to CategoryTree in 1.8

Have you seen CategoryTree yet? It looks promising, but the main disadvantage over your TreeView is that it doesn't replace the navigation menu. I'm currently setting up a Wiki where some kind of treeview would be good, since my article structure isn't flat, but most of them belong to a set of related items. Arjen Verweij

I had a brief look at it a while ago but couldn't get it fully functional. I'm looking at adding category functionality to the treeview skin. --Netocrat 00:33, 7 November 2006 (UTC)

Functionality similar to the category tree is now available in the treeview skin. --Netocrat 06:40, 1 February 2007 (UTC)

Some questions...

I wonder if it is possible to make the following things with the tree. Here is my tree for example:

Level1
- Sub1Level1
- Sub2Level1

...

So, while clicking on Level1 link, is it possible to send user to the first sub level page ie Sub1Level1?

And while clicking on Level1 link(not '+' icon) is it possible to expand the tree to see sub levels?

Thank you in advance.

--Loki 13:35, 12 July 2007 (BST)

Loki, neither of those things are currently possible - the best that the treeview can currently offer is for sublevels to be expanded by default by using the expanded parameter on the Level1 node. I suppose that what you're asking for is a new parameter: gotofirstsubonclick. This would be enough to expand the sublevels as well because selected nodes are always made visible. I'm not sure how generally useful this would be but if I find the motivation I'll implement it. --Netocrat 03:10, 16 July 2007 (BST)

Feedback and Questions from Kai

Greetings from Munich, Germany! I just stumbled over your extension yesterday. I am using Mediawiki 13.1 and I was pleasently surprised, how smoth it integrated without problems, how well the documentation was and how visual apealing the skin is. But of course, my main interest is the functionality of the skin (otherwise I wold not have downloaded it at first place).

I maintain a site with highly hirarchical content (see http://hegel.net ). The total system has some 3000 nodes (per language, but I plan seprate wikis per language, like in wikipedia) with up to some 10 levels (see for e.g. te tree at the bottom of page http://hegel.net/en/e3233333333.htm . ok, while I have a big and fast server, I can live for performance and memory reasons with lesser hirachy levels in the wiki at the moment). Now I am in the process of integrating a wiki with the option of later moving this into the wiki. I am curently working on the German version at http://wiki.hegel-system.de . You will get a bit the idea. Currently, I am replicting the hirarchy with manual created ascii graphics for every article, your solution would be much better.

However, I have some questions/problems with this:

In the firt place, most articles wil be empty and only later will incrementaly they become filled (or not). Is it possible to let leafs empty in your tree?
I see some problems when the hirarchy depends on article names with the complete path:
- first, such articles becomes much too long both for writing and reading (imagine article name of level 10!).
- then, such article names become useless for wiki-links: they are so long that it is no more practical to simply linking to them by writing their name and the brackets around them, also, you would need a title around each such link.
- last but not least, when you change the hirarchy (we often have such adgustments here and there), there is a need to change the complete namings and all links, that is a maintenance nightmare.

It would be much better, if we had the optional possibility to define the hirarchy ourself, based on the (unique) article names alone. In this regard, a cross between your nice skin and the ability to define the tree from a page like in the mediawiki TreeAndMenu extension would probably be the best (howver, may be this is also possible right now, as it seems that you also allow definition of static menu items, so one could also define a complete menu out of static menu items, right?).

Another sugestion: wouldn't it be easier to create a javascript js-file out of the tree and include that file in the actual pages? (it could have parameters for the curent node and similar). That way, you would need to send this file only once, not with every page. And when you have static pages, you would not even have the need to update it.

Alos, why so you have the edit button now *left* from the article subheadings? Is this configurable? --Kai 07:18, 18 September 2008 (BST)

A response to Kai

Hi Kai,

Thanks for the feedback. I'll get straight into your questions:

"In the firt place, most articles wil be empty and only later will incrementaly they become filled (or not). Is it possible to let leafs empty in your tree?"

Yes, this is possible, but of course you need to let the skin know about it somehow, and the way that you do that is to define the node in the treeview's configuration page (by default MediaWiki:treeview). So, for example, if the page "System of Science" exists, and the page "Logic" underneath that page does not yet exist but you want it to be shown in the treeview, then you would need to add the following lines to MediaWiki:treeview, somewhere underneath the directive "* [[]] IMPORT pruneleafs" (towards the end; this directive means "bring into the treeview at this point all articles from the top-level - and below - of the main namespace but only if they have nodes beneath them"):

* [[[System of Science]]] NODE
** [[[Logic]]] NODE

Note in particular to use three square brackets, not two, because these are not entire article titles that we are referring to, but "sub-contexts" (i.e. a phrase between colons in the article title).

"It would be much better, if we had the optional possibility to define the hirarchy ourself, based on the (unique) article titles alone. In this regard, a cross between your nice skin and the ability to define the tree from a page like in the mediawiki TreeAndMenu extension would probably be the best (howver, may be this is also possible right now, as it seems that you also allow definition of static menu items, so one could also define a complete menu out of static menu items, right?)."

Yes, exactly. Using the NODE directive you can statically define any treeview that you like. When you use double square brackets rather than triple square brackets, you are referring to an entire article title, rather than just a sub-context, so - for example - you could define part of your treeview statically (in the MediaWiki:treeview config page) like this:

* [[System of Science]] NODE
** [[Spirit/Mind]] NODE
*** [[objective Spirit/Mind]] NODE
**** [[Ethical Life]] NODE
***** [[Some Very Long Article Title|The Short Version of the Article Title to Display in the Treeview]] NODE

If you take this approach, then your article titles need not contain any colons whatsoever. Note with regard to the last line that as in ordinary MediaWiki links, the pipe symbol allows you to change what is displayed as the link's (in this case the treeview node's) text.

There is another option - you could use the IMPORT or GRAFT directives to set up small hierarchies based on colons in the article title and then slot them into your treeview where appropriate. You might decide, for example, that you will have no more than two colons in any given article title. So you might have Top-level:Level2:Level3, and then you might have Level4:Level5:Level6, and to set this up to display properly in the treeview you could use this set of directives in your treeview config page (remembering that the first one already exists):

* [[]] IMPORT pruneleafs
* [[[Top-level]]] NODE
** [[[Level2]]] NODE
*** [[[Level3]]] NODE
**** [[Level4]] GRAFT

You could use a mix-and-match approach incorporating both of these techniques if you wanted to.

"Another sugestion: wouldn't it be easier to create a javascript js-file out of the tree and include that file in the actual pages? (it could have parameters for the curent node and similar). That way, you would need to send this file only once, not with every page. And when you have static pages, you would not even have the need to update it."

I'm not quite sure what you mean here, but the treeview is in any case not static - note in particular that the nodes beneath "This article" change for each page; and the nodes beneath "Accounts" change based on who is currently logged in.

Kai: OK, I see. One may need to take care of these dynamjcaly, but this could be possible I think. Let me first excplain my idea: I see a three step algorythm: first, calculate the tree, then create a javascript containing a with a ragged array or similar out of that tree, that is then sent to the client. The idea is to change this then constructed javascript file as less then possible, so that we do not need to resend it on every page. in the last step, we need to account for some dynamics: may be the treeview could have an update button, instead of automatic updates when things change, this would mean more performance and less traffic. When you change within the tree, you could automaticaly change the focus in the tree. If you want to add soem general edit menu items to the node and remove them when the focus is lost, you could do this in the js as well. when you want to adjust to individual settings for the node, you could either also import them in the tree aray in the first palce, or you could call a server api, that just sends information about the curently selected node and update your node acording to that information (kind of ajax, I guess). However, I assume that if tzhis is possible, it may need a major rewrite and I don't know if it is worth the pain (technicaly, it would bea rther cool however and generate a nice user experience as well). May be something like this is also available in parts in the current ajax libraries floating around?

I could raise a few objections to some of what you've proposed, but in general it seems workable. The main problem is one which you identified yourself: it would take a (semi-)major rewrite, and I don't have the motivation to go about that rewrite. To be honest, one of the reasons that I decided not to send the entire treeview in a single go was the pure "cool factor" of load-on-demand. Ostensibly though I was concerned about not sending excessive data in the case of very large treeviews, but your solution would avoid that because (most of) the treeview would be sent once only (the javascript file would be cached in the browser and only downloaded again if the server informed the browser that it had changed, so we needn't have an update button). --Netocrat 20:22, 22 September 2008 (BST)

"Alos, why so you have the edit button now *left* from the article subheadings? Is this configurable?"

Ah, thanks for picking up on that - I'd noticed it but not payed any attention to it. I've fixed it so that it looks the same as in the Monobook skin now.

"Currently, I am replicting the hirarchy with manual created ascii graphics for every article"

Note that using the <treeview> tag you can embed part of the treeview into your page - in particular you might find the "showthis" parameter of this tag to be helpful.

Also note that I've just released a new version of the Treeview skin which fixes a few bugs and which adds the "showthis" support that I just mentioned - I recommend that you upgrade to it.

Please let me know if you have any other questions or comments.

--Netocrat 06:23, 22 September 2008 (BST)

Wow - super cool! Thanks a lot! This is very helpfull. I will look into this and later come back to you. Where would I download that mentioned latest version? --Kai 17:19, 22 September 2008 (BST)

Please see the top of this page - under "News"; it's version 1.4 beta. --Netocrat 20:22, 22 September 2008 (BST)

Ok, great, but at the moment, I do not see a version 1.4 beta anywhere on this page? (searching this page only reveals one 1.4 entry, this one her, nothing on the top - 1.3 is the lastest beta mentioned there. I also tried the search function to look thru your board, but without success). --Kai 09:52, 23 September 2008 (BST)

Doh, sorry - that edit got lost when I rolled back my messy edit - I didn't realise that it would roll back multiple edits at the same time. It should be there now. --Netocrat 10:24, 23 September 2008 (BST)

Bug reports from Sjdavis

Hi Sjdavis - I read through your bug reports and I noticed that you eventually removed them all from this page, apparently because you resolved them all - could you please let me know what you had to do to resolve them if there's anything that I need to fix in the code? Cheers mate. --Netocrat 01:04, 23 January 2009 (UTC)

From clc-wiki

Contents

Bug reports

Cyrillic encoding problem

Link problem in IE

Troubles with installation / mediawiki 1.9.3 / Diagnose empty or invalid hierarchy

A response

A response

Comments, suggestions and other feedback

TreeView structure as table of content

When will the treeview skin be publicly released?

Comparing TreeView skin to CategoryTree in 1.8

Some questions...

Feedback and Questions from Kai

A response to Kai

Bug reports from Sjdavis

Views

Personal tools

Site_logo

Search

Content_hierarchy

Tools