Phillip - Wow! Thanks! - this really clarifies for me.
On Apr 29, 5:17 pm, Philip <[email protected]> wrote: > 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). Yes, I see --- let's step back a moment, can we. This, in the nitty-gritty of it, I see is a bug, but it raises a higher level "bug": Core (gluon / SQLTABLE) is coupled into things it perhaps shouldn't be so tightly coupled with: View, and details of values that are the domain of the application (if this was not so, then SQLTABLE wouldn't need to know, and there wouldn't be a bug, do you agree?). I think this is about data containment. RIght now, there is coupling. That this bug took long to find suggests its at the periphery of the problem space (if it were smack-in-the-middle, lots of people would have already complained). But - if the bug (as it looks to me) is because of something gluon or SQLTABLE, specifically, should not be involved with (format, data passed around between app and client / view --- that's _way_ at the other end of where gluon should be), then (in that terminology) your proposal takes an imperfectly (but innappropriately) coupled situation, and solves it by completing / patching --- _increasing_ the coupling. The fundamental problem wtih that: at some point, something else from the business-logic (i.e. controllers and models at the application level) will change, and someone will _yet again_ have to patch a situation. I think the real solution shoudl be to look at what SQLTABLE is doing (in this case, sorting is DEFINITEVLY a view operation), and just _get out of that functionality all together_. While the motivation for making useful, common things easily available is good, and I have no problem with that, I think the positioning of where it is done needs to be adjusted. This (in my mind) is calling loud and clear for a plugin. Of course, a plugin could still be too coupled to your controller, so there is more structural stuff to think about here, but I suggest that a simple code / patch solution is probably not the right one here. Can anyone suggest how to pull sorting out of SQLTABLE into a plugin, and in a way that won't break backward compatability? - Yarko > 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 <[email protected]> > wrote: > > > I am confused... or missing something... > > > On Apr 29, 3:35 pm, Philip <[email protected]> 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
