Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 12, 2008, 09:26 UTC
- Message-ID
- <200812121026.07694.jnareb@gmail.com>
- In-Reply-To
- <87y6ymxf4k.wl%seb@cine7.net>
On Fri, 12 Dec 2008, Sébastien Cevey wrote:
Show 8 quoted lines
> At Fri, 12 Dec 2008 03:03:55 +0100, Jakub Narebski wrote: > > > And no, we don't need to sort by categories first. Let me explain > > in more detail a bit. > > Thanks for the detailed explanation, I understand your preference. > But as you said, it's a bit arbitrary, I think none is completely > obvious.
First, I feel a bit bad for derailing this patch. Currently gitweb does not do pagination of projects list; it is not even possible in a sane way with current way project searching/selecting is implemented. So the whole build_projlist_by_category() respecting $from and $to is moot point.
So if we don't use it, even if it is nice to have for the future, we don't need to pay cost of extra stable sorting.
Show 34 quoted lines
> > I don't really have a strong opinion about which is best, but just to > illustrate what made me go for the solution B, let me show another > example: > > name / date / cat > 1 2006 A > 2 2003 B > 3 2005 B > 4 2003 A > 5 2000 A > 6 2008 C > 7 2007 C > 8 2001 B > 9 2005 A > > We then sort by name and split in pages of N=3 (sorted by cat on each > page): > > A:sort(name) split(max=3) subsort(cat) > 1 2006 A 4 2003 A 9 2005 A > 2 2003 B 5 2000 A 8 2001 B > 3 2005 B 6 2008 C 7 2007 C > > B:sort(cat) subsort(name) split(max=3) > 1 2006 A 9 2005 A 8 2001 B > 4 2003 A 2 2003 B 6 2008 C > 5 2000 A 3 2005 B 7 2007 C > > With B, we have the second top-entry (2) relegated to the second page, > which might be surprising because we ordered by name. But what I find > weird about A is that because of the per-page category sorting, the > "top-sorted entries at the top" isn't true either (page 3). We have > "reshuffled" the result of 'sort(name) split(max=3)' on each page.
[...]
Show 22 quoted lines
> It's perhaps even more apparent if we sort by date: > > A:sort(year) split(max=3) subsort(cat) > 1 2006 A 9 2005 A 4 2003 A > 6 2008 C 3 2005 B 5 2000 A > 7 2007 C 2 2003 B 8 2001 B > > B:sort(cat) subsort(year) split(max=4) > 1 2006 A 4 2003 A 3 2005 B > 9 2005 A 8 2001 B 7 2007 C > 5 2000 A 2 2003 B 6 2008 C > > It feels kind of unnatural that not only projects are not sorted by > date on each page (they are inside categories), but moreover > categories are spread over all pages. > > > I guess it depends on your use case, and whether categories are > important or known by the user. I personally don't really care (I > never split stuff into pages in the gitweb I use), so I can do a new > version of my patch that does A if you prefer, just let me know. I > just wanted to clarify that both solutions sort of suck :-)
Well, with version A you can (I think) simply change
foreach my $cat (sort keys %categories) {to
foreach my $cat (sort
{ cmp_cat($projlist, \%categories, $oi, $a, $b) } keys %categories) {to have the following output (see the difference on page 3)
A':sort(name) split(max=3) subsort(sort(cat,name)) 1 2006 A 4 2003 A 7 2007 C 2 2003 B 5 2000 A 8 2001 B 3 2005 B 6 2008 C 9 2005 A
where sort_cat might be something like (we took advantage that categories in %categories have at least one project):
sub cmp_cat {
my ($projlist, $cats, $oi, $a, $b) = @_;
my ($aa, $bb);
# projects in categories are sorted, so we can compare first
# project from a category to sort categories in given ordering
$aa = $projlist->{$cats->{$a}[0]};
$bb = $projlist->{$cats->{$b}[0]};
if ($oi->{'type'} eq 'str') {
return $aa->{$oi->{'key'}} cmp $bb->{$oi->{'key'}};
} else {
return $aa->{$oi->{'key'}} <=> $bb->{$oi->{'key'}};
}
}-- Jakub Narebski Poland