RequireJS/AMD Module Forms

By on November 4, 2010 12:02 am

The CommonJS AMD proposal defines an elegant, simple API for declaring modules that can be used with synchronous or asynchronous script-tag based loading in the browser. RequireJS already implements this API, and Dojo will soon have full support as well. The API for defining modules is as simple as:

define(, , );

This simple API can be used in a variety of different ways for different situations.

NoSQL Architecture

By on May 11, 2010 12:03 am

The NoSQL movement continues to gain momentum as developers continue to grow weary of traditional SQL based database management and look for advancements in storage technology. A recent article provided a great roundup of some of the great new technologies in this area, particularly focusing on the different approaches to replication and partitioning. There are excellent new technologies available, but using a NoSQL database is not just a straight substitute for a SQL server. NoSQL changes the rules in many ways, and using a NoSQL database is best accompanied by a corresponding change in application architecture.

The NoSQL database approach is characterized by a move away from the complexity of SQL based servers. The logic of validation, access control, mapping querieable indexed data, correlating related data, conflict resolution, maintaining integrity constraints, and triggered procedures is moved out of the database layer. This enables NoSQL database engines to focus on exceptional performance and scalability. Of course, these fundamental data concerns of an application don’t go away, but rather must move to a programmatic layer. One of the key advantages of the NoSQL-driven architecture is that this logic can now be codified in our own familiar, powerful, flexible turing-complete programming languages, rather than relying on the vast assortment of complex APIs and languages in a SQL server (data column, definitions, queries, stored procedures, etc).

Resource Oriented Programming

By on May 9, 2010 12:07 am

The REST architecture has become increasingly recognized for its value in creating scalable, loosely coupled systems. REST is presented as a network interaction architectural style, not a programming methodology. However, the principles of REST can actually be very meaningfully and beneficially applied in the programming realm. We will look at how the resource oriented approach of REST can be applied as principles for programming language usage and design. The motivation for looking at REST should be clear. Little in history has been as ridiculously successful and scalable as the web, and REST is a retrospective look at the principles that were employed in designing the core technologies of the web, particularly HTTP. Applying such proven principles to our application design will certainly be beneficial.

Roy Fielding‘s REST architecture is broken down into seven constraints (and the four sub-constraints of the uniform interface). The individual concepts here are certainly not new, but collectively looking at these concepts as resource oriented programming may provide an interesting new perspective. I will also look at how these principles are exemplified in Persevere 2.0 in its object store framework, Perstore, and its web stack Pintura.

Slacker Databases Break All The Rules

By on March 24, 2009 12:20 pm

At first glance, the Persevere database looks like most of the others. You push pairs of keys and values into it, and it stores them away. But that’s just the beginning. Persevere provides a well-established hierarchy for objects that makes it possible to add much more structure to your database, giving it much of the form that we traditionally associate with the last generation of databases. Persevere is more of a back-end storage facility for JavaScript objects created by AJAX toolkits like Dojo, a detail that makes sense given that some of the principal developers work for SitePen, a consulting group with a core group of Dojo devotees.

Continue reading

Managing Server Structures in Persevere

By on January 15, 2009 12:54 pm

Persevere‘s latest release includes new functionality for creating clean, organized application directory structures, complete with a testing framework. Persevere now has an improved set of command-line options including a server generator, which makes it easy to build an application server directory that can be version controlled separately from the Persevere core files. The new server structure also includes a mechanism for building unit tests for Persevere.

Easy Exploration of Dojo Data Stores

By on January 14, 2009 2:01 pm

Dojo 1.3 includes a new tool for working with data stores. The Dojo data API is a pervasive part of Dojo; there are a variety important widgets that use the API and numerous data stores that implement the API. However, often data stores are only accessible through the application that is being built, and developers are dependent on working UIs (that are constantly under development) for store interaction. The StoreExplorer is a new development tool built by Ben Hockey and I, designed to debug and interact directly with data stores to make it easier to understand the data provided by the stores, directly interact with that data, and thereby pinpoint issues in the widget-store stack.

Getting Started with Persevere Using Dojo

By on July 23, 2008 6:48 am

This post is written for Persevere 1.0 and Dojo 1.3. If you want to get started with Persevere 2.0 (recommended), take a look at this post. Dojo 1.6 and newer has a new data API as well.

The Persevere server is an open source JSON application and storage server. Persevere pairs well with Dojo; the Dojo Data paradigm has a strong correlation to Persevere’s data storage structure. Virtually everything you can create or action you can perform with Dojo Data can be persisted in Persevere’s data storage including subobjects, arrays, circular references, and functions. Combining Persevere with Dojo allows you to rapidly develop simple database applications with create, read, update, and delete (CRUD) capabilities with minimal effort.

Client/Server Model on the Web

By on July 18, 2008 7:48 am

Prior to the popularity of the web, client/server applications often involved the creation of native applications which were deployed to clients. In this model, developers had a great deal of freedom in determining which parts of the entire client/server application would be in the client and which in the server. Consequently, very mature models for client/server development emerged, and often well designed optimal distribution of processing and logic could be achieved. When the web took off, the client was no longer a viable application platform, it was really more of a document viewer. Consequently the user interface logic existed almost entirely on the server. However, the web has matured substantially and has proven itself to be a reasonable application platform. We can once again start utilizing more efficient and well-structured client/server model design. There are certainly still technical issues, but we are in a position to better to build true client/server applications now.

JSONQuery: Data Querying Beyond JSONPath

By on July 16, 2008 12:04 am
Notice: We recommend reading our newer post on RQL.

A new data querying tool for has been added to Dojo 1.2. JSONQuery is a new module intended to succeed and improve upon the JSONPath module introduced in Dojo 1.1. JSONQuery provides a comprehensive set of data querying tools including filtering, recursive search, sorting, mapping, range selection, and flexible expressions with wildcard string comparisons and various operators.

JSONQuery provides safe evaluation with language agnostic expressions that prevents arbitrary code execution. It also uses intuitive result-based evaluation that allows successive query operations. Furthermore, the new JSONQuery module provides significant performance improvements, with 20-100x faster execution with the common filter operation on large arrays than the JSONPath module. JSONQuery generally supersets the functionality of JSONPath and provides syntax that matches and behaves like JavaScript where the syntax intersects for maximum ease of use.