The most important thing to know, which isn't documented in too many places, is that your returned JSON must have a 'numRows' key/value in it. See the bottom of this page: http://www.dojotoolkit.org/book/book-dojo/part-3-javascript-programming-...

Without numRows, the grid will always think you only have as many rows as are in the initial result set ... there won't be "enough" scrollbar to move up or down, which would normally cause the grid/QueryReadStore to issue additional ajax requests for data. Using Firebug you'll see it issue requests, with some extra parameters to control the paging (like, for example, start=10&count=50 and the next request would be start=60&count=50, etc.). That's tacked onto the request automatically.

D

Look at this example, if you haven't seen it already:
http://archive.dojotoolkit.org/nightly/checkout/dojox/data/demos/demo_Qu...

I've checked it a couple of times over the last few weeks, and the grids are just gray boxes in FF2, didn't check other browsers.

Yeah I saw that too, I think I even maybe opened a bug on it in their trac system .. or, I at least meant to :-)

Anyway, you can go back a couple of months (or probably even newer than that) and see a working version of that. For example:
http://archive.dojotoolkit.org/dojo-2008-07-15/checkout/dojox/data/demos...

I am using the latest 1.2 code, with a QueryReadStore and a DataGrid. It's in markup ... it may not be the best code (I just got it working, fyi), but I'm basically just doing something like this:

var blah_store = new dojox.data.QueryReadStore({
                                serverQuery: {somefield:7},
                                urlPreventCache: true,
                                url: "someURL/moreURL"
                            });

and...

and blahLayout is defined just like any normal grid layout. Then the JSON returned is just like any example for an ItemFileReadStore, except that I also have a numRows field and value at the top level. numRows is the TOTAL number of rows, which could be like 9000 or whatever ... that is used by the grid so it knows how big to make th scrollbar, etc. As you page down, it automatically fetches in 50-item increments (the rowsPerPage value), and that ends up on the GET's query-string. So it will automatically issue requests that look like:

http://someURL/moreURL?somefield=7&start=0&count=50

and then as you page down it will issue another like:

http://someURL/moreURL?somefield=7&start=50&count=50

Your server-side code must be able to handle that URL and return results appropriately. Obviously, the 'start' value is equivalent to 'OFFSET' in SQL and 'count' is equivalent to 'LIMIT'. 'somefield' is the query .. that's optional .. you can use it to filter the results from the server somehow. Also, note that if the user hits one of the grid header fields (to sort), and you have serverSort as true (which I assume you would), then it adds a 'sort=fieldname' to the http GET request, like so:

http://someURL/moreURL?somefield=7&start=50&count=50&sort=somefield

where 'somefield' is one of the field names in your layout.

Hope that helps...

Dylan Tynan

It cut out part of my code ... let me try it without the angle brackets around the div and the end-div and see if it'll take it...

div dojoType="dojox.grid.DataGrid"
        title="sometitle"
        jsid="blahgrid" id="blahgrid" 
        store="blah_store"
        clientSort="false"
        rowsPerPage="50"
        query='{somefield: "7"}'
        structure="blahLayout" 
    /div

Dylan Tynan

Back in 0.9 days, we wrote an extended class for QueryReadStore to have our own custom _filterResponse function as well as some url translation for some of those query string parameters for the server.

With the adoption of the numRows parameter, certain parts of the base QueryReadStore code had changed and those changes needed to filter down into our extended class. in particular the refactoring of the code that moved part of _fetchItems to _xhrFetchHandler with addition of numRows code is what was needed.

I've always hated that _fetchItems was such a big chunk of code, and that all of it as well as _filterResponse had to be modified in any extending class. For us, we still have to do it, but it's at least a smaller set of code now.

Thx for looking into it, turns out my issues were elsewhere, I'm sure it will be helpful for others.