Paginate: sorting by multiple fields in default_order - TurboGears

Message from discussion Paginate: sorting by multiple fields in default_order

Joel Pearson

More options Nov 15 2007, 12:20 am

From: Joel Pearson <j...@pythonica.com>

Date: Wed, 14 Nov 2007 22:20:53 -0700

Local: Thurs, Nov 15 2007 12:20 am

Subject: Re: Paginate: sorting by multiple fields in default_order

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

Jorge Godoy wrote:
> Em Wednesday 14 November 2007 03:41:17 Joel Pearson escreveu:

>> @paginate("company", default_order="company.region,-company.billing_date")

> I'd rather have a list here:
> default_order=['company.region', '-company.billing_date']

I agree that a list is clearer; I used a string to avoid changing the data type
of default_order.

>> 2. If so, does this seem like a reasonable new definition of default_order?
>> Old definition: "a single field name"
>> New definition: "a single field name or a comma separated list of field
>> names, where each field name is optionally preceded by a dash (-) to
>> indicate reverse order"

> As I said, I prefer using a list to mean a list and a string when
> referring to a string.
> A simple "isinstance(default_order, basestring)" would be able to
> differentiate which is which.

I see what you're saying-- allow default_order to be either:
A) a string containing a single field name, or
B) a list of strings that each contain a single field name
and then use "isinstance" to process each case accordingly.

Good idea. I've updated my code to reflect that change.

>> The ability to reverse the ordering from within "default_order" makes the
>> "default_reversed" parameter effectively unnecessary. However, for the sake
>> of compatibility I left it in, and made sure that all combinations of
>> default_reversed (True or False) and having a leading dash (or not) in
>> default_order work as expected.

> Did you also made it a list? Because if we have more than one value, then
> default_reversed can have different behaviours for each member of the
> list...

> Or it should check if there's just one "order" column, while raising an
> exception if you have multiple columns.

Actually, I was thinking that default_reversed could be eliminated entirely in
some future release (like 1.1 or 2.0, not 1.0.4).

I prefer these:

@paginate('table', default_order='-field1')
@paginate('table', default_order=['field1', '-field2'])

to these:

@paginate('table', default_order='field1', default_reversed=True)
@paginate('table', default_order=['field1', 'field2'],
default_reversed=[False, True])

If default_reversed was going away in a future release, it could remain a
single True/False value that works just the way it always has, by reversing the
sort order of the first (or only) field in default_order. This maintains
compatibility with existing applications (which only have a single field in
default_order), while allowing complex sort orders (using a leading dash when
needed) for new applications.

The only use case I can think of for expanding default_reversed into a list is
that it is somewhat easier to programmatically toggle the True/False values in
a list structure (default_reversed) than it is to add and remove the leading
dashes in a list of strings (default_order). The price you pay for having "more
than one way to do it", however, is the potential for confusing application
code like this:

# what's the actual order?
@paginate('table', default_order=['-field1', '-field2', 'field3'],
default_reversed=[False, True, True])

along with the additional logic in paginate.py to calculate the actual sort
order using both default_reversed and dashes in default_order.

All things considered, I'd prefer to (eventually) phase out default_reversed,
rather than expand it, but I welcome other opinions. :-)

- Joel
--
Joel Pearson

Reply to author Forward