dstore 1.1 released

By on April 17, 2015 12:21 pm


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.

Minimizing Dijit Instances in dgrid

By on April 14, 2015 11:22 am


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.

Memory Consumption: the Externality of Programming

By on March 17, 2015 11:35 am

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting. As developers, we wisely work for better performance by understanding performance characteristics, and verifying performance with tests. However, one aspect of performance can be particularly difficult to assess, and its effect can easily be underestimated. Memory consumption can have a large impact on performance, but in ways that can easily be missed and ignored.

Optimized Navigation: Isomorphic Resources

By on February 27, 2015 8:14 am

When building web applications, developers often face the dilemma of whether to use traditional server-side rendered pages, or client-centric applications that rely on Ajax/JSON data requests, with client-side rendering of data. These two approaches also tend to dictate navigation (among other things), leading to traditional page navigation or a single-page application (perhaps with hash-based navigation). With the traditional approach, content is delivered in HTML form, relying on browser-driven page loads for different views. However, modern applications with more sophisticated user interfaces, often use a single-page style, controlling events, view updates, and relying on Ajax-style communication with the server to load additional content, typically in structured object format, like JSON. The traditional approach naturally works well with search engines, and browser navigation and can be quickly rendered by the browser. Single-page applications facilitate well structured user interfaces, with clean separation of presentation and data. But is there a way to combine the best of both worlds?

Introducing dstore

By on November 17, 2014 1:24 pm

dstore 1.0

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.

REST tips

By on June 24, 2014 11:50 am

At SitePen, we have long been advocates for building web applications on a RESTful architecture. Over the last several years, it has been exciting to see organizations increasingly provide RESTful endpoints for the Dojo-based front-ends that we support and develop. A well-designed REST backend can be a excellent foundation for manageable, scalable applications, that will be ready to evolve into the future. I wanted to share a few tips for designing a set of RESTful services.

Local Database Stores

By on June 17, 2014 10:57 am

Modern browsers have powerful new database capabilities that enable applications to store data locally, and perform advanced indexed queries without a network connection. Applications can be built with offline support without any disruption to data interaction, including searching. However, these database capabilities have traditionally been difficult to use across browsers since Safari only supports WebSQL (although version 8 is slated to include IndexedDB support), and Firefox and Internet Explorer only support the W3C’s IndexedDB API (Chrome supports both). And these two interfaces couldn’t be more different, making it very problematic to write applications that work offline on all the major browsers.

But, it is now much easier to access these database capabilities. By taking advantage of the consistency of the Dojo object store implementation, in version Dojo toolkit version 1.10, dojox/store now includes object store implementations for IndexedDB and WebSQL, along with a wrapper that will automatically delegate to the appropriate store implementation based on browser support. With a single common interface, you can retrieve, update, add, and delete objects, and even perform sophisticated queries in exactly the same way with the different underlying storage implementations.

Building on Persevere

By on May 29, 2014 11:11 am

Persevere is a server-side JavaScript framework that we started several years ago to help build RESTful web applications with clean separation of concerns, encapsulation, and the consistency of JavaScript in both client and server. Recently, we had the opportunity to work on a project that used the full capabilities of Persevere, leveraging many of its features and leading to some improvements as well. We wanted to share some insights on how to best leverage some of the unique features of Persevere.

Looking Ahead with Stores

By on May 16, 2014 1:25 pm

Part of the foundation of the Dojo architecture is the data store layer. Dojo applications are built on a uniform interface for accessing different data sources, to make it possible for different presentation components to be used with different data models. We are continuing to work towards evolving and refining our data layer at SitePen. Lately we have been working on a new project called dstore, that represents our vision for the future of the Dojo data layer. The dstore project will include a number of improvements and new capabilities, including an improved querying API, better notifications, more stores, and a data modelling system for individual objects.

Private Matters: Convention and Closures

By on January 6, 2014 11:10 am

Many object-oriented programming (OOP) languages provide a way to define private properties and methods. This allows objects to encapsulate functionality and state information. This encapsulation leads to a clear distinction between the internal implementation and a clean external interface.

However, JavaScript does not have a native mechanism for declaring private properties and methods, in the same sense that other object oriented languages do. But, there are a few techniques that we can use to achieve the same results.