SQLFORM.grid created from request.vars - search, pagination etc breaks

962 views
Skip to first unread message

Mandar Vaze

unread,
Oct 23, 2012, 7:51:28 AM10/23/12
to
Hi,

I recently added a new SQLFORM.grid which is created based on parameters selected in previous controller function. 
The query used is based on the request.vars passed from previous controller. I can see the grid alright.
(Something like this http://www.mail-archive.com/web...@googlegroups.com/msg30769.html Except instead of SQLTABLE I am using SQLFORM.grid)

Problem : 
The "extended" functionality of SQLFORM.grid doesn't seem to work like "View", "Search", and Pagination etc. Since they call the same controller (but there are no request.vars this time)

I was able to workaround for "view" where I check if request.args(0) =='view', and then redirect to another controller, where record ID is available as request.args(2)
But I don't know what to do for Search and Pagination.

I think there is a better way, and I wouldn't have to "workaround" for "view" either.

Here is pseudo-code just to give better idea :

def chooseView():
     
# Form with two drop downs where user chooses parameters for the report
     
# Similar to index function from the URL provided below
     
if form.accepts(request.vars, session):                                    
         redirect
(URL(r=request, f='viewReport', vars=request.vars))


def viewReport():
     
# Following is hack, wanna get rid of if possible
     
if request.args(0) in ['view']:                                            
          redirect
(URL('default', 'viewRecordDetails', args=request.args, vars=request.vars))
     
# Checks like filter1, filter2 exists in request.vars
     filter1
= requesr.vars.filter1
     filter2
= requesr.vars.filter2


     reportQry
= db((db.table.field1 == filter1) & (db.table.field2 == filter2))
     grid
= SQLFORM.grid(reportQry.query, create=False, editable=False, csv=False, deletable=False, searchable=True)
     
return dict(grid=grid)


Problem now if when I click on search, viewReport is called with request.vars as follows :
<Storage {'keywords': 'Text I searched'}>

When I click on View button in the grid, viewReport is called with request.args as follows :
['view', 'table', '83']
I was able workaround this as explained above.

I did not capture data when clicked on one of the numbers in the pagination bar. But I guess viewReport is called with some request params.

Please suggest what is the correct way to handle so that "built-in" functionality like view, search, pagination etc work.

(On web2py 2.0.9 and 2.0.8 - both have problem - in case it matters)

Thanks in anticipation

-Mandar






lyn2py

unread,
Oct 23, 2012, 8:02:18 AM10/23/12
to web...@googlegroups.com
I ran into a similar requirement recently. I used sessions to record the vars I needed.

However I can do so because the user is required to click on links to move around the site (they can't guess the urls). That way I can control the variables stored on session.

I didn't understand your requirement fully (got lost halfway) when I posted this. So I am suggesting but I'm not sure if that will solve your issue.

Mandar Vaze / मंदार वझे

unread,
Oct 23, 2012, 9:13:11 AM10/23/12
to web...@googlegroups.com
lyn2py : Thanks. Your suggestion worked (you correctly understood the requirement)


I was thinking in the direction of "store the vars in some sort of globally accessibly place" - But wasn't sure how.
Storing in the session seems right way to do it.

When/where should I "clean" these variables from session ?
In case user directly accesses second URL (without going thru first URL to select the search criteria) they might see incorrect results - since controller function will use "old" values 

- Mandar


--




lyn2py

unread,
Oct 23, 2012, 11:25:31 PM10/23/12
to web...@googlegroups.com
In my case I was setting over the same session var, and each time checking the same var.

Cliff Kachinske

unread,
Oct 24, 2012, 1:24:49 AM10/24/12
to web...@googlegroups.com
Why the redirection?

grid accepts a "search_widget" parm where you can create your own widget.  Why not figure out how to use that?

Admittedly the manual doesn't help much, but you have the source code in gluon/sqlhtml.py.

Mandar Vaze / मंदार वझे

unread,
Oct 24, 2012, 1:44:26 AM10/24/12
to web...@googlegroups.com
It is NOT just search. As I mentioned I also need other "built-in" functionality like pagination, view etc.

--
 
 
 

lyn2py

unread,
Oct 24, 2012, 2:40:57 AM10/24/12
to web...@googlegroups.com
When/where should I "clean" these variables from session ?
In case user directly accesses second URL (without going thru first URL to select the search criteria) they might see incorrect results - since controller function will use "old" values 

I suggest to ensure that URLs must be followed. Not possible to clear the session vars especially if search result has more than one page. Use user_signature=True for your SQLFORM.grid 

Niphlod

unread,
Oct 24, 2012, 5:56:21 AM10/24/12
to web...@googlegroups.com
isn't this a little silly ? we have an args parameter to the grid but not a vars one....

Could you try to test a little mod to the source.....

- open gluon/sqlhtml.py and scroll until "def grid("
- add a vars={} default parameter
- a few line below, there's "def url(**b)"
- change with this
   
    def url(**b):
            b
['args'] = args + b.get('args', [])
            vars
.update(b.get('vars', {}))
            b
['vars'] = vars
            b
['hash_vars'] = False
            b
['user_signature'] = user_signature
           
return URL(**b)


Create a grid with
grid = SQLFORM.grid(table, vars=dict(mycustomvar='mycustomvalue'))

In theory, the 'mycustomvar' parameter should be passed along with navigation into the grid without causing problems.

Disclaimer: use customized vars, not the ones the grid uses (like order, keywords, search,page, etcetc). Should be safe though, in case of collision the grid wins over the vars you passed on instantiation.

Mandar Vaze / मंदार वझे

unread,
Oct 24, 2012, 11:53:42 PM10/24/12
to web...@googlegroups.com
Even if we were to add ability in grid to take vars as params - it may not be useful in my case (I think) because when controller is invoked for view/search/pagination, "original" request.vars are lost (that is why saving in session is needed) 

-Mandar

--
 
 
 

Mandar Vaze / मंदार वझे

unread,
Oct 24, 2012, 11:57:41 PM10/24/12
to web...@googlegroups.com
"user_signature=True" is the default which I am not changing - so I guess I should be OK. I'll try "directly accessing second URL" to  confirm.

Thanks !!!!

-Mandar


Niphlod

unread,
Oct 25, 2012, 3:42:58 AM10/25/12
to web...@googlegroups.com
a) you can have the search form to do a get instead of a post. In that way when the user presses the button "submit" he is redirected to your page, and that page can load the grid with the parameters specified into request.vars
b) with this you are sure that the parameters are reset if the user stops navigating your grid

Alen Cerovic

unread,
Oct 25, 2014, 5:20:08 AM10/25/14
to web...@googlegroups.com
two years later I am struggling with same problem, is grid vars parameter now included in web2py?

Mandar Vaze

unread,
Oct 27, 2014, 6:00:15 AM10/27/14
to web...@googlegroups.com
Current code looks like this : https://github.com/web2py/web2py/blob/master/gluon/sqlhtml.py#L2031
See if it helps

-Mandar

P.S. : I posted original query (2 yrs ago) but as mentioned earlier in the thread - I ended up using session variable though.

Alen Cerovic

unread,
Oct 27, 2014, 6:23:45 AM10/27/14
to web...@googlegroups.com
Hi Mandar,

as you pointed me to source it seems there is still just args parameter.

I tried with session.vars but somehow I was loosing those vars and it just did not feel right to me.

I ended up switching to args and pass those request.args to grid as args parameter.
It works now but I like it more with vars because it is easily readable

thnx
Alen

Alex Glaros

unread,
Jun 5, 2015, 3:00:34 PM6/5/15
to web...@googlegroups.com
vars passed to controller doing grid search disappear

seem that updating w2p to keep the vars after grid search would be a good improvement

thanks!

Alex Glaros
Reply all
Reply to author
Forward
0 new messages