Login Register
Home » Support » Forums » DojoX (dojox.*) » Dojox Grid Development Discussion » Dataset Maintenance using DojoX Grid and QueryReadStore

Dataset Maintenance using DojoX Grid and QueryReadStore

Submitted by Shoarc on Sat, 07/12/2008 - 06:25.

I used the Dojox Grid and the Dojox QueryReadStore to create a simple dataset maintenance app. This is actually a widget that I named custom.Grid. I wrote a short article on this (here) and plan to make updates on this.

This widget features server side paging and sorting as well as adding, editing, batch editing, deleting, batch deleting, and filtering. The article includes information on how to use these functions on the demo. The demo can also be found (here).

Any feedback and comments would be helpful. Thanks!

‹ smooth transition when scrolling grid using dojox.data.QueryReadStore Is this production ready ›

Some suggestions on your grid demo

Submitted by Maine on Sat, 07/12/2008 - 09:06.

Always nice to see demos like this! (I know that getting to know dojo's grid component requires some work.) You asked for feedback, so let me suggest few improvements:

  1. Namespace: "custom" is hardly that unique that it would prevent collisions.
  2. Virtual scrolling: instead of paging by moving from a page to page, you could try virtual scrolling, so that you'd let the grid to fetch pages when the user scrolls down.
  3. Edit in grid: instead of popping up a modal dialog, you could let the user to edit the data straight in the grid. (Another nice grid feature that you might want to try.)
  4. NumRows: Since 1.1(.1? or maybe in nightlies) you can use numRows parameter instead of making a separate query to fetch the row count.
  5. "Edit selected rows": does nothing when there are multiple selected. How were you planning to handle editing several rows at the same time?
  6. "Database table maintenance": sort of implies that you'd be able edit different tables in any database. However, when this is not the case, how about calling it something else, like "grid editor for data set x"? :)

Thanks for the suggestions

Submitted by Shoarc on Sun, 07/13/2008 - 03:09.

Thanks, it took me quite a while to go through a lot of the documentation and spend hours debugging. Here are my thoughts:

1. Namespace: I will be changing this to com.rubicorp.grid
2. Virtual scrolling: I did consider virtual scrolling, but for very large data sets I did not want to use a small scroll bar. Perhaps with the current paging, combined with virtual scrolling would be best?
3. Edit in grid: At first I wanted to do this and it would be nice for small data. But I wanted to work with a modal 'editor.' The reason being is that I plan to migrate this website[rubicorp.com] to Dojo. This would include submitting articles and images and handling the information in the datatable in the DojoX grid. Writing articles, such as ones at the site, and uploading images and specifying the title, caption, etc, would be better done in a modal editor as opposed to editing in grid. Do you think I should allow an option of what kind of editing the user would like?
4. NumRows: When the QueryReadStore refreshed, it called both getRowCount and requestRows. Since, without modifications, the getRowCount would return the count of all rows even if a filter is specified. This would cause the grid to show the filtered data, but with ?'s in the rest of the rows( rows that should not be there). So I modified the getRowCount in the QueryReadStore to a method similar to requestRows but intead retrieves the row count.
5. "Edit selected rows": By selecting multiple rows and clicking edit, this should have opened up the editor dialog with empty fields. I am not sure why it did not work on your end. For example, you select the first 2 rows, click edit, and place 15 in the last textbox. The script uses dojo.foreach with the selected rows and updates each of the rows with values inputed, in this case 15. If the text boxes are left blank, they are not updated. For this example, trying to change the first column should result in no change since the data is keyed by the first column. This is working for me using FireFox 3 and IE 7.
6. "Database table maintenance": I'm not sure what you mean here. Currently, for me to create a grid, i would instantiate the grid will some specific parameters and then call startup. The grid has its own template which includes the two filtering selects and the dojox grid. The grid would then be created and I would be able to edit the data. For now I have assumed a struts/java backend and requires that the user to pass in the WebApp name and action name tied to each function( for this example, RubicorpPrototype and glacct.do ). Calling the grid with different parameters would allow me to modify other tables in the database. The editor also is created from a template which the caller should supply.

Thanks again for the feedback. I hope to hear your opinions on these points. Thanks again!

Some suggestions on your grid demo

Submitted by Maine on Wed, 07/16/2008 - 22:02.

Glad I could help. To clarify my ideas:

  1. Namespace: this longer namespace sounds good to me.
  2. Virtual scrolling: scroll bars work nicely in excel even for 10k rows. :) In dojox.grid there's a switch not load every row in between current and the scroll target/end row - good for large data sets .
  3. Edit in grid: I see your point - totally depends on the characteristics of a data set.
  4. NumRows: But if it's the backend doing the filtering, it will return you correct number of rows. As I tried to explain, in Dojo 1.1.1 you don't need to change getRowCount, if you pass numRows-property with every response alongside items-property. (Maybe these discussions would help you: Handle numRows sent by the server and QueryReadStore breaking Grid scrolling)
  5. "Edit selected rows": ok, my mistake - i expected it to show some data instead of empty fields.
  6. "Database table maintenance": the name reminds me of phpmyadmin, so i though that it might be good to indicate that it is intended for certain data sets only. Someone here wanted to do something like phpmyadmin, but maybe he got bored in the point when he realised that in order to use a grid for several database tables one would need to create the structure separately for each table. (could be done with sql describe, but that a different story.)

Thanks again. Additional Update!

Submitted by Shoarc on Mon, 07/21/2008 - 23:10.

Thanks for clarifying your points.

  • 2. I will look into if I am able to do paging with the virtual scrolling. For now, I like having physical pages.
  • 4. This is what I might be doing in my next update for this this grid. So far it is not working. I am using the original v1.1.1
  • 5. I think I will display instructional text in the fields asking the user to specify values, or leave them alone for an unchanged value.
  • 6. My mistake, I will change the name to clarify!

Additionally, another example grid is up on the demo page. I wrote a little something about it (here) so that you can try the demo itself. The demo is on the same url (here) as in my first post. As you will read in the article, this next demo shows one of the purposes of using a dialog as an editor for the data in the grid. Once again, comments are appreciated!