• 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.
This means that I get the order:


try this:

Index: Store.pm
--- Store.pm    (revision 11101)
+++ Store.pm    (working copy)
@@ -1544,7 +1544,7 @@
     $web =~ s#\.#/#go;

     my $handler = $this->_getHandler( $web );
-    return $handler->getTopicNames();
+    return sort { lc $a cmp lc $b } $handler->getTopicNames();



This would be preferable, but would it have a large inpact on performance?


Looking at the code I see that handler getTopicNames is called from a lot of places where order does not really matter. So sorting the list in these cases will be overkill.

That would plead for using sort in TWiki.pm: TWiki:_TOPICLIST only.

But there is also Func:getTopicList. Would it be useful to have an optional sort parameter?

-- AC

I would be very careful, add no-case sorting only if performance is not impacted. Better to test with many topics in a web, such as 10K topics.

-- PTh

I read from this that the sort parameter would be useful. With a note about inpact on performance.


I do not feel strongly one way or the other of case insensitive sort (assuming the performance is OK.)

-- PTh

Note that sorting case-insensitive will result in variable random orders, as 'ThisTopic', 'ThistopIC' and 'THISToPic' will all be treated as equivalent and will end up in an unpredictable order relative to eachother.

I recommend that this be discarded.


I want to avoid perceived randomness. To a user who is not a programmer it will not be obvious that Weblogs will be below (often out of sight) WebTopicList. And in Crawford's example the topics will at least be listed in each other's neighbourhood, which I prefer to the current situation.

-- AC

I think the case-insensitive is best too. People are not programmers in general so they do not understand that A and a are far apart in the alphabet.

But before anyone jumps and implements anything, measure performance first. We should not just change and add a note about a possible performance hit. We should try it and measure and then decide. If the performance drops significantly then it is not worth it


I really can't see this as "Normal" priority, compared to other issues at that priority, so regrading to "Low".


One thing to try is to configure I18N with a locale such as en_US.ISO-8859-1 - you may find it does case insensitive sorting automatically, though you would also require a one-line fix from Item3680.


I am setting this to "no action required" - it had no action for many years and is not important.

-- Peter Thoeny - 2013-10-17

Summary TOPICLIST is sorted case sensitive
ReportedBy TWiki:Main.ArthurClemens

SVN Range Wed, 12 Apr 2006 build 9798
AppliesTo Engine

Priority Low
CurrentState No Action Required
WaitingFor Someone to fix it

TargetRelease n/a

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r18 - 2013-10-17 - PeterThoeny
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback