Open Bug 482890 Opened 16 years ago Updated 2 years ago

Add a sort option for XUL tree columns

Categories

(Core :: XUL, enhancement)

enhancement

Tracking

()

People

(Reporter: BijuMailList, Unassigned)

References

()

Details

https://developer.mozilla.org/en/XUL/tree

Tree control is already providing a way to hide/unhide the columns.
I wish by default it gives a text(case-insensitive) sort option also.

In addition can we get also column header attributes like
  * sort-type - say Number, Date, CaseSensitive etc.
  * sort-function - a JS function to do comparison like Array.sort
and cell attribute
  * sort-value - an alternate value instead of displayed text.

This will solve many independent bugs like, bug 76170
Blocks: 275223
Do we have sort logic from another function that we can use or copy to make this simpler to do?
> In reply to comment #1
> Do we have sort logic 
http://en.wikipedia.org/wiki/Cocktail_sort

Brendan, can you please ask somebody in the js-engine team to suggest best algorithm here.

Also trigger a "sorted" event after the sort for corresponding nodes.
Postpone screen painting till sorting over to avoid flickering.

I feel this should be a DOM method of all the nodes, see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026608.html
Summary: A Sort option on tree columns → Add a sort option for XUL tree columns
This is very simple; we don't need js core to do anything: we just need to write a simple function and make it applicable to XUL tables.

The primary question (beyond who writes it) is if this should be enabled by default for XUL tables.
(In reply to Biju from comment #2)
> > In reply to comment #1
> > Do we have sort logic 
> http://en.wikipedia.org/wiki/Cocktail_sort
> 
> Brendan, can you please ask somebody in the js-engine team to suggest best
> algorithm here.
> 
> Also trigger a "sorted" event after the sort for corresponding nodes.
> Postpone screen painting till sorting over to avoid flickering.
> 
> I feel this should be a DOM method of all the nodes, see
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026608.html

The way sorting is implemented now is that, in addition to what is displayed in the DOM, we have an ordered list in JavaScript which mirrors the treebox/listbox/etc. On click of a column, we resort our list in JavaScript, remove all the elements in the treebox and reconstruct it. As far as I know, the UI doesn't update until after JavaScript releases its thread control so it won't flicker anyway.

If this function is added to a treebox/etc, then it's going to have to do something similar and hold a second parallel representation of its items. Here's why:

1) Sorting DOM nodes is (relatively) expensive and messy, (e.g. swapping the position of two child nodes versus swapping two javascript objects in an array). So we have a simple O(nlogn) sorting algorithm with low overhead, and then O(n) DOM operations.

2) "sort-types" is just trying to handle the problem where our sort values are different from our displayed values. Clearly, one needs to be stored to sort, the other to be displayed.

This solution can be implemented I think if we added 1-2 properties to treecols. (an attribute so you can define a value -> displayed value, a comparator property). The treebox (parent) can look at whether any of the column children have a sortable property to see if it should keep a non-DOM copy of its items. The risk is that people will start abusing it and using it as a datastore or worse, having another copy of the data.
I don't think this will be heavily abused, unless it causes a security flaw somehow.  I'd be curious to know what solution was implemented in Thunderbird to sort emails in a folder, because I believe that's a XUL table (I'm not sure) and can support tens of thousands of entries--though I don't know any particulars beyond "it can do it."
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.