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.
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.
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.
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.
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.
One pretty common issue we get in the dojo-interest mailing list asks why
RoundRectStoreList.set("store", store); doesn’t actually appear to be setting the store properly? That is, the data in the RoundRectStoreList doesn’t actually render the data in the new store, but instead keeps old data rendered.
In this post, we will walk through creating widgets, or UI components in xstyle. CSS itself has a basic component-like unit, a CSS rule. However, xstyle enables a level of advanced UI for constructing rich components, beyond what can be specified with basic CSS. The simple extensions in xstyle allow us to generate DOM elements, respond to events, and encapsulate functionality for easy reuse and composition.