Yarko,
let me try to explain why I view this as a bug. SQLTABLE offers
the option of having the headers clickable to sort the table by any
one of the columns. I don't think it is unreasonable to expect that
clicking on one of the headers returns the same table with the rows
resorted. In the existing implementation this is only true for tables
at URLs which do not include any variables. Since the orderby
functionality is embedded in the SQLTABLE function, the resulting URL
is generated by SQLTABLE, not by the controller. For the controller to
pass the state to the new request (the sorted table as opposed to the
original table), it has to be able to pass the information about the
state to SQLTABLE. There is a precedent in the linkto parameter that
is used by SQLTABLE already. It allows the controller to specify the
URL for the hyperlink to edit or view an individual record from the
table. In the case of linkto, SQLTABLE makes no assumption about the
form of the URL that the developer would want as the hyperlink. With
the orderby parameter, however, SQLTABLE has built-in assumptions
about the form of the URL (i.e. that it has no variables attached to
it).
Maybe an example will make more sense. We have a simple controller
that is called with a URL that always has a customer variable
associated with it (for example from a menu selection):
def show_invoices():
customer = request.vars[customer]
return
dict(records=SQLTABLE(db(db.invoices.related_customer_id==customer).select(db.invoices.ALL),
headers={'invoices.date':''Date','invoices.amount':'Amount'},truncate=24,orderby=True))
Let's say the user clicks on a link to myapp.com/init/default/
show_invoices?customer=Fred, then the view correctly shows a list of
the invoices corresponding to Fred. Because we specified
"orderby=True" in the parameters of SQLTABLE, the table generated in
the view has each of the column headers as a clickable link to sort
the table. For example, the Amount column header is a link to the URL
"myapp.com/init/default/show_invoices?orderby=invoices.amount" We
have lost the customer variable.
-Philip
On Apr 29, 5:14 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
> I am confused... or missing something...
>
> On Apr 29, 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.
>
> THe web is stateles; two requests are not correlated - so I do not
> understand why this is a bug...
>
> response.vars holds all your responses from the client (browser) - it
> is up to your application to do something reasonable (i.e. preserve
> the value in a controller, if it's pertinent to the applicaiton).
>
> I do not see how / why this should be imposed on SQLTABLE.... you
> could certainly keep this in your table definition if you wanted....
>
> Maybe I'm missing something...
>
> - Yakro
>
>
>
> > * Relevant code: In the code visible here
> > -http://www.web2py.com/examples/static/epydoc/web2py.gluon.sqlhtml-pys...,
> > 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
