The Tech of SitePen Support August 19th, 2008 at 12:01 am by Kevin Dangoor
Protected Cross-Domain Access with Dojo’s windowName August 18th, 2008 at 3:25 pm by Kris Zyp
The new windowName module (dojox.io.windowName) now includes support for resource authorization as Neil Roberts described in his article on xauth. Now the windowName module can be used with a window.name enabled resources for simple (direct) access as well resources that require an authorization step.
The Dojo Toolkit and Deft August 3rd, 2008 at 12:09 am by Mike Wilcox
A new top-level package was recently added to the Dojo Toolkit called Deft — an acronym for Dojo Experimental Flex Technology. The Deft package was created and is maintained by SitePen’s Tom Trenka, taking advantage of Adobe’s new MPL licensing, and the corresponding APIs of the Flash Player. Most articles focus on Adobe’s Flex Builder, which isn’t open source or free. The majority of articles about Flex and the Flex Builder also put an emphasis on components developed using a combination of ActionScript and XML-based description files, known as MXML.
Instead of taking this approach, Deft focuses on ActionScript components created in support of the various projects within the Dojo Toolkit (mostly for DojoX). Deft source files are well organized based in part on the organization of other Dojo Toolkit projects, as well as the package structure required by the Flex compiler. Most Flex applications are based on the Flex AS3 Application class, which forces you to write at least one “controlling” MXML file in order compile your code. Instead of this, Deft components inherit primarily from the Sprite class — which allows you to write pure ActionScript code.
Secure Mashups with dojox.secure August 1st, 2008 at 6:44 am by Kris Zyp
The upcoming Dojo 1.2 release features a new comprehensive framework for building secure mashups with the dojox.secure project. This new project includes all the components necessary for safely loading untrusted code, advertisements, content, and widgets from other domains, validating that it is safe to execute, and providing a sandboxed environment and controlled subset of the DOM to interact with. Using traditional means, loading scripts from other domains is a great security vulnerability, every script has full access to the JavaScript environment and DOM of the source page. The alternate approach has been to use iframes, which greatly limits UI integration and programmatic interaction. With dojox.secure, untrusted scripts and widgets can be safely loaded directly into a web page with fine grained sandboxing of their capabilities, while still allowing them to access a controlled subset of the DOM and JavaScript environment.
Cross-Site XHR Plugin Registry July 31st, 2008 at 3:17 pm by Kris Zyp
Several new technologies are coming out for accessing resources from other sites. IE8 will include the XDomainRequest and the W3C is finishing the access control specification for enabling cross-site access for XMLHttpRequest, which will probably be implemented in next major release of all browsers, including Firefox. However, it will certainly take a long time for these new technologies to become pervasive enough to use them reliably and exclusively. Is there any way to leverage this technology immediately when these browsers are released? Yes! With Dojo’s new XHR plugin system, you can start making cross-site requests right away, using the new technologies when available, and a proxy server as a fallback, all while using the familiar dojo.xhr* methods. Your source code can still use this simple API while the registry can handle choosing the appropriate underlying transports for the situation.
Protected Cross-Domain Authentication with JavaScript July 30th, 2008 at 12:01 am by Neil Roberts
Google and Yahoo have JavaScript APIs that let you perform searches. Wikipedia has a JavaScript API that lets you grab data from its pages. These APIs can be accessed cross-domain with a transport method known as JSONP. JSONP works by allowing you add a script tag to your page which points to a URL on their server. The server outputs JavaScript that will call a method (defined as part of the query string in the URL), passing it JSON-formatted data.
You’ll notice that these services are read-only. I don’t currently know of any cross-domain JavaScript APIs that allow you to write data in any meaningful way. An example of this sort of data would be a way, through JavaScript, to update your status on a social networking web site.
Getting Started with Persevere Using Dojo July 23rd, 2008 at 6:48 am by Kris Zyp
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.
window.name Transport July 22nd, 2008 at 12:04 am by Kris Zyp
The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowName module, and it is very easy to make web services available through the window.name protocol. window.name works by loading a cross-domain HTML file in an iframe. The HTML file then sets its window.name to the string content that should be delivered to the requester. The requester can then retrieve the window.name value as the response. The requested resource never has access to the requester’s environment (JavaScript variables, cookies, and DOM).
Client/Server Model on the Web July 18th, 2008 at 7:48 am by Kris Zyp
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 July 16th, 2008 at 12:04 am by Kris Zyp
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.