Paginate: sorting by multiple fields in default_order - TurboGears

Message from discussion Paginate: sorting by multiple fields in default_order

Jorge Godoy

More options Nov 18 2007, 7:45 pm

From: Jorge Godoy <jgo...@gmail.com>

Date: Sun, 18 Nov 2007 22:45:13 -0200

Local: Sun, Nov 18 2007 7:45 pm

Subject: Re: [TurboGears] 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
  

Em Thursday 15 November 2007 03:20:53 Joel Pearson escreveu:

> 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])

Me too. :-)

> 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.

It could also be that:

if default_order[n].startswith('-'):
ignore_default_reversed() # ;-)

I.e., we don't allow cascading the two different options.

If default_reversed is going away, deprecated messages should be issued as
soon as possible so that people have time to update their code.

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

+1 from me, with deprecated messages.

--
Jorge Godoy <jgo...@gmail.com>

Reply to author Forward