Expressing all this in a ticket (instead of here) is the fastest way to get us to help you debug it. We aren't always super-duper responsive (the best practice is probably to open a ticket and then link to it in a post here). The developers of MooTools have only their spare time to fix stuff like this, and we really appreciate it when you help us fix things, but the less time we spend keeping track of bugs the better.
Take a break and post this to a ticket tomorrow or next week and we'll help you out. On Fri, Jun 17, 2011 at 2:42 PM, Chris Ghormley <[email protected]>wrote: > Aaron, > > I understand. I wasn't complaining about opening a ticket, it was just > the end of a long frustrating debugging session and I wanted to put > something down. I have been trying to figure it out on my own and > tweaking the source but the code still seems to be smarter than me at > this point. > > Chris > > On Jun 17, 12:19 pm, Aaron Newton <[email protected]> wrote: > > Hey Chris, > > > > By asking you to open a ticket I'm not trying to be unhelpful. The > problem > > is that posts like this tend not to catch the attention of committers or, > > even if it does, to drop off our radar, while the ticket system is our > place > > of record of stuff we need to fix. Further, it lets us go back easily and > > see the work that others do to help us understand the bug. If we think we > > fix the bug and find out later that we didn't, we have a single place for > > the history of the problem. > > > > I'd like to encourage you to open a ticket (just paste this message > below), > > maybe create a jsfiddle that demonstrates it, and, if you want to be a > real > > rock star, make changes to the code that you think address the problem > and > > send us a pull request. This is how the community helps make MooTools > > better. Opening a ticket is really fast and easy, I promise! > > > > Aaron > > > > On Thu, Jun 16, 2011 at 11:49 PM, Chris Ghormley > > <[email protected]>wrote: > > > > > > > > > > > > > > > > > I am back trying to figure out some details of HtmlTable sorting. The > > > requirement is to sort descending by date. If the user selects some > > > other sort column, the table should be sorted by that column first, > > > then by descending date. > > > > > Factoring out the date for the moment, let's just talk about a two- > > > column table. Suppose I want to sort on column 2 descending regardless > > > of the direction I am sorting column 1. > > > > > Column 1 contains: 1, 2, 1, 2, 1, 2 > > > Column 2 contains: b, c, a, b, c, a > > > > > When I click on column 1 to get an ascending sort I should get: > > > > > Column 1: 1, 1, 1, 2, 2, 2 > > > Column 2: c, b, a, c, b, a > > > > > Sorting descending on column 1 I should get: > > > > > Column 1: 2, 2, 2, 1, 1, 1 > > > Column 2: c, b, a, c, b, a > > > > > I have created a class called HtmlTable2 that overrides headClick so I > > > can catch clicks on the table header and call the sort method on my > > > secondary sort column with the prepare flag set (see below). The only > > > problem is that the sort method doesn't pay any attention to the > > > reverse flag unless the prepare flag is false. By repeated clicking on > > > the header I can sometimes get the sort direction I want, but it's not > > > what I was hoping for. > > > > > I suspect that I will be told to open a bug, but I wanted to report it > > > here first and request comments. Here's the class I am using: > > > > > HtmlTable2 = new Class({ > > > > > Extends: HtmlTable, > > > > > headClick: function(event, el) { > > > > > if (el.cellIndex!=1) { > > > this.sort(1, true, true); > > > } > > > > > this.parent(event, el); > > > } > > > }); >
