This will certainly make it easier to put a css class to the header cell depending on "change:direction". This will open the door for configuring an initial sorting for a grid upon initialization as well.

What additional changes, if any, would you like to see in this commit to accept it?

Tests :)

the sort logic should also be in the column, such as the makeComparator() and the sort function itself. Then the click handler can simply call this.column.sort(this.direction()). This is what I had monkey patched in my application to enable "saving" the column sort order for the grid.

I also added a sortType to the column definition which allowed me to dispatch a special comparator based on date, integer and the default locale case string sorting. I would use this from my version of the makeComparator factory to produce each type of comparator based on the setting.

@kriswill Or you could just trigger backgrid:sort on the collection.

This PR looks fine, just needs some tests.

well the reason I did it like this, is because I actually save the column settings. HeaderCell isn't a model, it's a DOM element with a click event. It just doesn't work for me to have it owning the comparator factory, or the sort state.

Oh, In my application I have a list of "Reports", each one has a selection of fields that map to columns, and it can be saved by name, edited, have it's columns rearranged, sorted and exported as a CSV.

I actually save the column settings

This is what this PR will do.

I guess the only thing that's missing is sorting automatically on initialization based on the column direction value. Can you do something about this @egeste ?

bingo! That's exactly it.

Automatically sorting on grid init can be done very simply inside HeaderCell's initialize function as well.

The problem I have with that is that it requires you to render the grid first. Or that the Grid has to exist. It seems to me that the Columns SHOULD be able to be used independently of any relationship to the Grid or it's sub-views. For instance, I provide a menu of available columns which allows the user to toggle a column's renderable bit.

Columns can already be used independently. It can be independent in the sense that you can do whatever you want to it what you can do with a Backbone.Collection. Moving all the sorting logic to Column defeats this purpose. What's the use of sorting the rows collection headlessly without being able to display them?

I'm not even sure I understand your concern. Are you trying to say you want to be able to programmatically sort a grid from an independent control that connects to the Columns collection only? If that's the case this PR can also be amended so that a HeaderCell can listen to its Column's direction attribute and sort the rows in the event listener.

In my application the steps are like this:

1. initialize the columns, use stored settings
2. make the comparator with the column(s) that are sorted (user defined)
3. initialize the collection with comparator (so the items are added in correct sort order)
4. initialize the Grid, render, show "Loading Sign"
5. fetch the collection, the Grid reacts to the collection
6. take down loading sign, user interacts, makes column setting changes, etc

I could just as easily have separated the logic for the acquiring the comparator for the collection. However, the minimalist in me would prefer there was only one factory defined for it. To me the HeaderCell is just UI, it shouldn't be involved with owning the factory for a collection comparator. The Column seems like the natural place for this.

Do what you want, but I think when you get to the sorting multiple columns feature, you'll find it easier to implement from the Columns object.