Uriel Katz wrote in to tell us that he’s burned his GearsORM framework to the ground to create the entirely new JStORM framework, announced in his blog. JStORM currently supports Google Gears, Aptana Jaxer, and Adobe AIR, but it’s still bleeding edge: no documentation yet, just code. But the feature-set is interesting:

* define your tables as models.
* full CRUD support.
* events on(Before/After)Delete/Save/Update.
* SQL LIMIT/OFFSET support.
* order by support.
* automatic creation of tables.
* selecting and deleting over relations.
* easy iterating with each syntax like in Ruby,support for query chaining and more.
* basic introspection support.
* transaction support.
* self relations.
* support multiple backends and multiple dialects,currently MySQL (in Jaxer only) and Sqlite (Jaxer, Gears and AIR).

Here’s an example of loading “Person” entities from a database using JStORM:

Looking forward to seeing some docs, Uriel ;-)

We were all very impressed with the work that the 280 North team did with 280 Slides, and they fulfilled their promise by opensourcing Cappuccino and Objective-J under LGPL:

Cappuccino is an open source application framework for developing applications that look and feel like the desktop software users are familiar with.

Cappuccino is built on top of standard web technologies like JavaScript, and it implements most of the familiar APIs from GNUstep and Apple’s Cocoa frameworks. When you program in Cappuccino, you don’t need to concern yourself with the complexities of traditional web technologies like HTML, CSS, or even the DOM. The unpleasantries of building complex cross browser applications are abstracted away for you.

Cappuccino was implemented using a new programming language called Objective-J, which is modelled after Objective-C and built entirely on top of JavaScript. Programs written in Objective-J are interpreted in the client, so no compilation or plugins are required.

The team has done a good job doing what many opensource projects miss, giving documentation and discussion. It will be interesting to see how others take this work and produce compelling Web based products. Let us know if it is you!

We have written about using window.name as a transport and Kris Zyp has just posted about how Dojo has created a new dojox.io.windowName module.

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).

You can access it in a simple way:

Kris then goes on to show how to use this with Web services and other scenarios, and explains why you may be interested:

This technique has several advantages over other cross-domain transports:

• It is secure, JSONP is not. That is, it is as secure as other frame based secure transports like fragment identifier messaging (FIM), and Subspace. (I)Frames also have their own security issues because frames can change other frames locations, but that is quite a different security exploit, and generally far less serious.
• It is much faster than FIM, because it doesn’t have to deal with small packet size of a fragment identifier, and it doesn’t have as many “machine gun” sound effects on IE. It is also faster than Subspace. Subspace requires two iframes and two local HTML files to be loaded to do a request. window.name only requires one iframe and one local file.
• It is simpler and more secure than Subspace and FIM. FIM is somewhat complicated, and Subspace is very complicated. Subspace also has a number of extra restrictions and setup requirements, like declaring all of the target hosts in advance and having DNS entries for a number of different particular hosts. window.name is very simple and easy to use.
• It does not require any plugins (like Flash) or alternate technologies (like Java).

MooWheel, the JavaScript connections visualization library, has been updated to version 0.2.

Updates include:

• New data format
• Text can now be hovered over, in addition to the dot
• Images can be added for each item

You can see the popular Twitter example
(thanks to Augsto Becciu, creator of TweetWheel).

Also, MooCirclePack has just been released:

MooCirclePack is another stunning visualization library that brings circle packing to JavaScript. It is great for data that can be represented by size (eg: an alternative to a bar graph), or data that can be represented amorphously.

There is a non-Ajax demo, and an Ajax one.

Ivan Bozhanov walked us through his jQuery-based tree component recently. The state of trees out there is interesting. YUI! has a nice, stable tree control but Dojo’s once feature-rich tree has been replaced with a fairly basic tree (i.e., doesn’t appear to have in-line editing and drag-and-drop still seems flakey; Dojo guys, correct me if I’m wrong) at the moment and jQuery UI lacks an official tree component (though a few tree plug-ins are out there); as you might expect, Ext JS has a nice tree component.

Let me highlight a few areas where jsTree stands out. First, it has some basic features that many trees out there lack:

jsTree allows the user to create, rename, reorder, move, and delete note (which is realised in a file-browser manner – eg. inplace)

It also has a rich event API which is fairly standard across most editable tree components, though the event types are finer-grained than in most trees I’ve seen (not sure whether that’s a good thing):

You can attach callbacks to almost every action:
– onbeforechange
– onchange
– onrename
– onmove
– oncreate
– ondelete
– onopen
– onclose

It also allows you to provide rules that govern what the user may or may not do based on the “type” of a node:

jsTree lets developers define rules for moving, selecting, deleting, and focusing nodes. The rules are based on developer-definable types of each node passed in the data (different sources define it differently). This limits the user in his actions. The developer can also attach inline rules which override global rules. One scenario in which these rules are useful is when you build a CMS and need a fixed number of top level nodes because of a design restriction.

While you could accomplish the same functionality with event handlers, it’s nice to have a simple built-in scheme that can be easily data-driven.

These rules are applied real-time as the user attempts to interact with the tree:

When you drag a node around a pointer tells you where you are about to insert it, and prevents the user from dropping anywhere against the rules. The warning is real time – as you drag and drop the pointer is replaced by a red cross if the action is against the defined rules. I’m still working on displaying definable text messages.

jsTree can be configured to reference a custom property in each node object to determine its type.

It also has built-in localization support; you specify string identifiers corresponding to the different languages that the tree should support on construction:

and then in this case each node in the XML tree fed to the component specifies its language:

In addition to XML data types, it also supports JSON and in-line HTML. But it also has built-in support for doing XSL transforms on XML data sources, including a scheme that lets you include flat data that it then makes into a hierarchy:

jsTree supports XSL transformations when using the XML data source option. This is a bit faster than javascript parsing. It includes an XSL stylesheet for transforming a flat list of entries into a tree. This can be useful if you use adjacency for maintaing a tree in a database. In such situations it is quite heavy on the server to dump the whole tree as you need N-1 queries where N is the number of nodes in the tree. With this XSL solution you can just dump the table flat out with id and parent_id attributes and the XSL will transform it into a nested structure.

Unfortunately, what jsTree is lacking is the visual refinement of many of the trees out there, but as jsTree is built on top of jQuery, we suppose Ivan can add that kind of polish easily.

For many data-driven applications, high-quality grid and tree components are really important; kudos to Ivan for some interesting ideas in jsTree. The docs are certainly better than some I’ve seen, but not as complete as I’d like.

Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!

As well as Firefox 3 support, Gears 0.3 includes:

• Ability to create desktop shortcuts with a snippet of JavaScript
• Improved support for customizing the installation flow and permission dialog
• Better support for sending complex objects to workers
• Detailed progress events for managed resource store updates
• And more…

Then, all of the videos from Google I/O sessions have been published.

I put together a playlist that includes Ajax and Gears related content:

Check out the great talks such as:

Gears

• Improving Browsers in New Ways: Gears++
• Google Gears for Mobile
• HTML 5, Brought to You by Gears
• Gears and MySpace – Search on the Client
• Taking Large-Scale Applications Offline
• Gears Case Studies

GWT

• Using GWT to Build a Diagramming Tool
• GWT and Client-Server Communication
• GWT Extreme by Ray Cromwell
• JavaScript and DOM Programming in GWT
• Resource Bundles and Linkers in GWT
• Deferred Binding with GWT

General Ajax

• Alex Russell on “Can We Get There from Here?”
• Spice up Your Apps with Google AJAX APIs
• Yours truly, Dion and Ben, State of Ajax: The Universe Is Expanding
• Steve Yegge on Server Side JavaScript

Wow, a lot of material there!

John Leach has created a very cool new open source project called Frizione (Italian for Clutch).

Frizione is a “JavaScript development, testing and deployment environment. It comprises a library agnostic set of tools for any type of browser based JavaScript development, which coincidentally has Gears support.”

You run Frizione as a Web server and it gives you a set of services:

Compressor Service

The compressor service takes a JavaScript file and removes comments and
unnecessary whitespace. This can be a destructive operation in that the original

JavaScript file can be overwritten, unless the -o option is specified – you have been
warned.

To invoke the service, send a POST request to /run_compressor, appending the
absolute JavaScript file path, with respect to the /Clutch root directory, as part of
the URL. Clutch will then compress the JavaScript file. Additional request parameters
can be set to modify the behaviour of the compressor, using the YUICompressor
command line options.

Fixture Service

The fixture service allows you to write text to hard disk. When sent a POST, the
service writes the POST data to the file specified in the URL, optionally modifying the
contents with parameter values specified in the POST request, using ERB.
To invoke the service, send a POST request to /run_fixture, appending the
absolute output text file path, with respect to the /Clutch root directory, as part of
the URL.

Join Service

The join (or concatenate) service uses ERB to join together a list of text files,
producing a single concatenated file. Each file can contain include commands
which contain relative URLs to other files to be included at the point of the include
command itself. This process can also be repeated within the included files (nesting).
To invoke the service, send a POST request to /run_join, specifying the absolute
text file path, with respect to the /Clutch root directory, as part of the URL. Clutch
will then create the joined (or concatenated) file. The to request parameter is
required to set the destination absolute URL of the resulting joined file.

JSLint Service

The original lint program analysed C source code for potential (and subtle)
malpractices likely to lead to run-time bugs. Modern C compilers now provide
sufficient syntactic and semantic checking that lint is now rarely required or used.

Fortunately for JavaScript programmers, Douglas Crockford has built a lint program
specifically for JavaScript, in JavaScript, called JSLint. Finding and removing
potentially poor code before unit testing is an essential process, at least for me.
Unfortunately, cutting and pasting code to the web page can itself be error prone.

Clutch alleviates this problem by creating static HTML pages that read in your
JavaScript code, which can then be analysed locally by JSLint. You only need create
the static HTML page once for each JavaScript file you wish to analyse.

To invoke the service, send a POST request to /run_jslint, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then produce a static HTML file under the /jslint folder, which
automatically loads the JavaScript file into the JSLint page. You may then wish to add
a link to this static HTML file in the /jslint/index.html page.

Test Service

The test service creates a run/view pair of static HTML files for a given JavaScript
file. The reasons for using two HTML files is explained in the ‘Unit Testing’ section
below.

It can also provide functionality similar to the join service. It can use ERB to join
together a list of JavaScript files, producing a single concatenated JavaScript file, but
only if the to parameter is specified.

To invoke the service, send a POST request to /run_test, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then create the two static HTML files.

The Unit Test Framework

The framework follows a similar pattern to the well known JUnit Java testing
framework.

Create your test methods in a plain JavaScript object, then wrap that object in a
clutch.unittest function call, as shown in the first example above. All functions
in your test object which begin with test will be executed by the unit test
framework, but the order of function execution is not guaranteed.

Before a testxxx function is executed, the unit test framework will execute a setUp
function in your object. After a testxxx function has been executed, the unit test
framework will execute a tearDown function in your object. Clutch provides a
default no-operation function for setUp and tearDown if none are defined in your
object.

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

• Caching can be done correctly, and once, by us… and developers have to do nothing
• Gzip works
• We can serve minified versions
• The files are hosted by Google which has a distributed CDN at various points around the world, so the files are “close” to the user
• The servers are fast
• By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
• A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

The second way to access the scripts is via the Google AJAX API Loader’s google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

You will notice that the version used was just “1″. This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of “1.8.2″ will select the obvious version. This is because a fully specified version was used. Specifying a version of “1.8″ would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for “1″ will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the “uncompressed” parameter like so:

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT’d ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don’t have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don’t use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

Paul Duncan announced today the release of PersistJS, a client-side JavaScript persistent storage library.

Currently the only reliable cross-platform and cross-browser mechanism for storing data on the client side are cookies. Unfortunately, using cookies to store persistent data has several problems:

* Size: Cookies are limited to about 4 kilobytes in size.
* Bandwidth: Cookies are sent along with every HTTP transaction.
* Complexity: Cookies are difficult to manipulate correctly.

Modern web browsers have addressed these issues by adding non-Cookie mechanisms for saving client-side persistent data. Each of these solutions are simpler to use than cookies, can store far more data, and are not transmitted along with HTTP requests. Unfortunately, each browser has addressed the problem in a different and incompatible way.

Trying to address the need for client-side storage sans browser-specific techniques or browser plugins, Paul has created an abstraction layer that allows developers to use most of the most common client-side storage mechanisms via a common interface. It currently supports persistent client-side storage through the following backends:

• flash: Flash 8 persistent storage.
• gears: Google Gears-based persistent storage.
• localstorage: HTML5 draft storage.
• whatwg_db: HTML5 draft database storage.
• globalstorage: HTML5 draft storage (old spec).
• ie: Internet Explorer userdata behaviors.
• cookie: Cookie-based persistent storage.

Other notables features include:

• Small (9.3k minified, 3k gzipped)
• Standalone: Does not need any additional browser plugins or
  JavaScript libraries to work on the vast majority of current
  browsers.
• Consistent: Provides a consistent, opaque API, regardless of
  the browser.
• Extensible: Custom backends can be added easily.
• Backwards Compatible: Can fall back to flash or cookies if no
  client-side storage solution for the given browser is available.
• Forwards Compatible: Supports the upcoming versions of Internet
  Explorer, Firefox, and Safari (Opera too, if you have Flash).
• Unobtrusive: Capability testing rather than browser detection, so
  newer standards-compliant browsers will automatically be supported.

Eugene Lazutkin has written a very thorough post on dojox.lang.aspect a module that takes AOP seriously in JavaScript.

As someone who has been to a couple AOSDs (the AOP software conference) and was excited to see AOP on the scene, it is good to see someone who gets it working on the JavaScript side.

Of course, we all get the interception piece. It is very easy to just wrap a method to do something new in a dynamic language such as JavaScript. But the power (and complexity!) of AOP lies in the world of joinpoints, pointcuts and worm holes :)

For these, a dynamic language isn’t as helpful. Eugene delves into the world and takes us to the module from first principles. He then builds a timer aspect which can be used to profile an application. Along with a memoizer and other useful cross cutting concerns, you end up with good ole Fibonaci:

Memoization got results too:

On my computer with Firefox 3 the calculation of 1-order (regular) Fibonacci number of 15 (987) took ~48ms without memoization and 0-1ms after memoization. The calculation of 0-order Fibonacci number of 15 (32768) took ~1155ms without memoization and the same 0-1ms after. As you can see this technique can work wonders without much investment of time.

Just like with Java, we won’t see every developer worrying about pointcuts day to day, but instead, simple usage of existing advice will become very useful indeed.