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 via email: [1].

Contents

News

  • 6 May 2007: Version 1.3 beta of the Treeview has been released fixing the bug with empty configuration in Mediawiki 1.9 as reported by Kati below, as well as with the new <treeview> tag to implement the table-of-content idea of Potwhale below.
  • 28 March 2007: Version 1.2 beta of the Treeview has been released fixing the bug with non-ascii character-sets causing load-on-demand to fail, as reported by Loki below.
  • 22 March 2007: Version 1.1 beta of the Treeview has been released with three bug-fixes: node sorting when merge=sort, edit box formatting buttons displaying and KHTML and Opera css fix files being included properly.

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>

<div id="_����������__1"><input type="hidden" class="notfound">_����������__1</input></div>

<form action="#">

<input type="hidden" id="expandednodes" value="" />

</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>

<div id="_testnode__1">

<ul>

<li id="tv.L__testsubnode__1">

<img alt="[o]" title="leaf node" width="13" height="13" class="icon" src="/wiki/skins/treeview/leaf.png" />

<span class="text">

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

</span>

<input type="hidden" id="dbttl._testsubnode__1" value="Test_Subnode" />

<input type="hidden" id="baseurl._testsubnode__1" value="/wiki/index.php/Test_Subnode" />

</li>

</ul>

</div>

<div id="_𢰵񃱰?𳱰񃰟_1">

<input type="hidden" class="notfound">_𢰵񃱰?𳱰񃰟_1</input>

</div>

<form action="#">

<input type="hidden" id="expandednodes" value="" />

</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 id="_����������__1">

<input type="hidden" class="notfound">_����������__1</input>

</div>

<form action="#">

<input type="hidden" id="expandednodes" value=""/>

</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 [2].

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:

  1. Wait a few days until I release a new version that solves this problem
  2. 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)
Retrieved from "http://www.clc-wiki.net/wiki/Planning:Treeview_skin:Feedback"
Personal tools
Tidy_icons
not logged in