There is also a bug in appadmin that when you sort you get the list sorted, but if you browse the next 100 records, the sorting reverses itself. Do you think this would fix that bug as well?
-- Thadeus On Thu, Apr 29, 2010 at 3:35 PM, Philip <philip.el...@gmail.com> wrote: > I'm not sure the patch submittal process, nor am I confident that my > solution is the best way to solve the issue, but I'd like to propose a > solution. > > Problem: > * Situation: SQLTABLE with orderby=True is used on a URL that includes > any variable. For example, URL is myapp.com/init/default/invoices? > customer=Fred, and we'll say the table has three columns, Invoice > number, Date, and Amount. > * Bug: If you then click on one of the column headers in the table to > sort the table, for example Amount, the resulting URL that gets called > loses the variable. In this example, the resulting URL is myapp.com/ > init/default/invoices?orderby=Amount. We have lost the customer > variable we passed to the original URL. > * Relevant code: In the code visible here - > http://www.web2py.com/examples/static/epydoc/web2py.gluon.sqlhtml-pysrc.html#SQLTABLE.__init__, > the problem code is on line 1091, " _href=th_link+'?orderby=' + c" > > Proposed Solution: > I think this requires adding a parameter to SQLTABLE which holds the > vars passed to the current URL. I'll call it :vars. For simplicity, > let's assume that vars always has the same form as request.vars, so > that the canonical way of calling SQLTABLE in these circumstances in a > controller is to add a parameter 'vars=request.vars'. Since it only > comes into play when orderby=True, we can insert a few lines in > SQLTABLE as follows. These lines would follow line 1089. > > var_url='' > if length(vars) > 0: > for v in vars: > var_url += '&' + v + '=' + vars[v] > > Then line 1091 would be changed from "_href=th_link+'?orderby='+c" to > _href=th_link+'?orderby=' + c + var_url > > Please let me know if there is a better way to submit patches or to > ensure that a proposed patch such as this has no unintended side > effects. And, of course, if others have a better way of solving this > problem, please speak up. > > Regards, > Philip > > >
