New table sorting library

[Jim]

At the top of the page, the stats page is not showing the color on distance traveled for me for active only now.

Fixed.

I am also getting an "out of memory" error whenever I try to use the route finder.  I want to think it was something on my end, but I am unsure.

Works for me, but I've only tested so far on one high-end MacBook Pro.  It's possible that we won't be able to use the sortable.js functionality on a table that starts with 90,000+ rows without overwhelming memory capabilities of many browsers.

[Markkos1992]

Maybe it is the 90,000 rows, but the current version on the main Travel Mapping site is still working fine for me....

It seems to happen in the tmstage version when I click in the route name search field or elsewhere.

[Jim]

Maybe it is the 90,000 rows, but the current version on the main Travel Mapping site is still working fine for me....

It seems to happen in the tmstage version when I click in the route name search field or elsewhere.

I think it's the extra memory used when the sortable code is applied - it attached things to every row.  I could see this easily doubling or more the memory requirements in JS to store and deal with the sorting of the table compared to the version that didn't have this.  Remember that the current production version doesn't support sorting at all.

[Markkos1992]

I guess it is best to go without sorting the Route Finder for now until we can find ways to reduce memory to do it.  We can already somewhat sort it beyond the route name anyway so it is not that huge of a deal to be able to sort the columns.

[Jim]

I've got a version of findroute on tmstage now that puts in a button you can use to enable column sorting.  I don't think it should have any memory (or other) resource utilization beyond what the production version has until you click that button to turn on the functionality.

[Markkos1992]

Thank you.  The Route Finder on tmstage now works fine for me without sorting.

[michih]

@Jim, have you changed anything in the last three hours? The user page tables are sorted by region and system name now. I'm quite sure that it was by clinched miles (region) and % clinched three hours ago - just as it should be!

I haven't, but I bet I need to specify an initial sorting that differs from the order that comes out of the DB in those cases.

The version on tmstage should now sort as it did before.

Is this the behavior we want?

I think so.

I am not sure why the by-region table sorts by distance traveled while the by-system sorts by % traveled.

I'm used to it and like it as-is. I don't wanna see this being changed.

[michih]

I've got a version of findroute on tmstage now that puts in a button you can use to enable column sorting.  I don't think it should have any memory (or other) resource utilization beyond what the production version has until you click that button to turn on the functionality.

It doesn't run out of memory for me but it takes a lot of power (browser slows down) and it's not working correct nor is usable (sorting takes 3-15 seconds and I easily managed that sorting by tier was a total mess 2-2-2-3-3-3-3-2-2-2....). There is no added value (right now).

[Jim]

I've installed the latest on the production server, including the button that turns on optional sorting for findroute.  I think everything else is as good as or better than it was before, and no one who doesn't want to use the sorting on findroute is forced to press the button to turn it on.

[michih]

It seems that HB systems are sorted by code instead of country (first) + tier (second) now. Since the country column is the first one, it starts with Netherlands, followed by Africa, Finland and Albania now.

[Jim]

It seems that HB systems are sorted by code instead of country (first) + tier (second) now. Since the country column is the first one, it starts with Netherlands, followed by Africa, Finland and Albania now.

Initial sort is now however it came out of the DB.  I can pretty easily make it sort the way it was before, if that's the preference.  I don't know how people tend to look at that list.  I always just search for the system code I am looking for.

[michih]

It seems that HB systems are sorted by code instead of country (first) + tier (second) now. Since the country column is the first one, it starts with Netherlands, followed by Africa, Finland and Albania now.

Initial sort is now however it came out of the DB.  I can pretty easily make it sort the way it was before, if that's the preference.  I don't know how people tend to look at that list.  I always just search for the system code I am looking for.

I think we should keep it as-was because people are used to it. We can change it if there is any improvement but I don't see it. The system code is just a "TM internal code". Sure, old hands are used to the code but newbies don't. Newbies likely look for the country or region first.

[Jim]

While I'm in hb/index.php again, any thoughts on the current practice in the "Country" column that any country name longer than 15 characters is replaced by its 3-character code?

[si404]

While I'm in hb/index.php again, any thoughts on the current practice in the "Country" column that any country name longer than 15 characters is replaced by its 3-character code?

It's fine for USA, obviously. DRC is OK. But TTO, STP, etc are a bit "huh?".

[Jim]

Now on tmstage is a version of hb/index.php that sorts by default first by country, then breaks ties with tier, then breaks ties with system name.  If no one notices any problems with that on Saturday, I'll install it on the main server.