Throughout the course of June, the dgrid StackOverflow tag saw a series of questions regarding usage of dgrid and dstore with the Django REST Framework. Based on the flurry of closely-related questions that popped up, I became quite curious as to the actual level of difficulty involved with this integration.
Over the holiday weekend here in the US, I decided to let that curiosity get the better of me. In this blog post, I share the results of that endeavor, stepping through the process of customizing a simple Django Rest Framework project to communicate with dgrid using dstore’s Rest store.
We have released dstore version 1.1, which features a new set of stores for local DB storage. This feature provides the ability to store data locally in browsers, and use high-performance querying capabilities through the disparate technologies of IndexedDB and WebSQL (and localStorage), through the consistent dstore interface. Complex queries can be formulated in your application, and data can retrieved from local database storage with the same APIs and query format as is currently supported with other stores. Queries can then be automatically translated to SQL or cursor operations, depending on the underlying technology available.
Dijit and dgrid provide a powerful set of user interface components, allowing for fast construction of sophisticated web applications with excellent performance and interactivity. However, one particular configuration of dgrid that can impact memory and performance: heavy use of persistent Dijit editors within grid cells. The dgrid’s
Editor plugin makes it very easy to leverage various Dijits for editing cells. However, using the default “always-on” mode, where a Dijit is instantiated for every editable cell, in combination with a several columns with numerous rows can quickly consume a lot of memory and create a noticeable drag on your application’s performance.
Dijit editors can help provide some fantastic functionality, with powerful widgets for auto-completion, date input, and validation. In this post, we’ll review two approaches to achieving advanced data input in dgrids that are designed for heavy data manipulation without compromising performance or memory consumption.
While a more recent advancement allows us use the HTML5 file API to retrieve contents from files, this approach is not universally supported in web browsers as yet. Instead, we will access data from user-uploaded CSV files using the following steps:
- Upload a file to the server
- Retrieve the file from the server
- Load the data into an easy-to-use format
Dojo has long distinguished itself with a robust and complete application architecture. And the foundation of this architecture has been the store interface, providing clean separation and consistent interface between presentation and data sources. We are committed to continuing to improve this architecture, and in this pursuit, we now releasing dstore, a next generation object store interface and set of data modeling components.
dstore is an exciting new package that provides a number of significant improvements over the prior data store framework, including a more fluent querying API, improved event notification, advanced cross-store filtering, and a more modular mixin system that allows us to easily combine components with alternate format support, advanced querying support, and more. In this post, we want take a brief look at these new features and improvements. From there, you can explore the tutorials and documentation that we have written for this new package.
dgrid 0.3.16 has been released! It includes the following improvements:
- Various improvements to keyboard accessibility, including interoperation with the ColumnSet mixin and editor column plugin
- Additional ARIA attributes for improved accessibility in the ColumnHider and Pagination extensions
- Improvements to logic for drag-and-drop operations with DnD extension
More information on dgrid 0.3.16 is available in the release notes.
We are working hard on our next release, dgrid 0.4!
Dojo’s store API is a common interface for providing data to user interface widgets, such as dgrid, Dijit Select, and Dojo Charting. The beauty of having a consistent API is that once you’ve defined an interface for a data source, that data becomes easily available to all widgets that support the store API. We’re going to look at how you can create a basic, read-only
dojo/store API-compliant module for accessing GitHub’s API (specifically, GitHub issues), an example of implementing your own Dojo store.
dgrid’s Selection mixin
dgrid is SitePen’s lightweight, modular, and easily extensible modern grid component, designed for use with AMD and Dojo. The Selection and CellSelection mixins enable selection of rows or cells, both from mouse or keyboard actions and programmatically. Adding selection functionality to a grid is a simple as mixing in the desired module:
dgrid, SitePen’s next-generation Dojo data grid, has been serving many users’ needs for over two years. Over that time, we have been steadily adding extensions, making improvements, and addressing issues. However, the process of reporting and fixing defects becomes an endless cycle — one we’ve arguably already been stuck in long enough — and it’s time to set our sights higher for the long run.
SitePen’s next-generation grid component, dgrid, is designed to be modular and lightweight, allowing you to only load what you need. It has been designed to work well in Dijit-based UIs, but functionality specific to interacting with Dijit is provided in a module that is not loaded by default. Without this module, two common problems often occur:
dijit/registry module will not find dgrid based on its ID
- The grid will not size correctly when placed inside a layout container widget, such as