Alex Moore wrote in to highlight a couple of developments in the Ext JS community. First, the Ext JS roadmap has been updated with goals for the 2009-targetted 3.0 release:

# All new lightweight, high-speed core base library
# Flash Charting API
# Ext.Direct - Remoting and data streaming/comet support
# Integrated client-server data binding/marshaling of updates
# ListView component
# Enhanced Button and Toolbar components
# ARIA/Section 508 accessibility improvements
# CSS updates for reset style scoping and easier custom theming
# Update the Ext event registration model
# Ext.Ajax enhancements

Second, Alex provided a link to a preview screencast of a new Ext JS visual developer tool, currently in early development:

Back in May, we posted a story about “the other JIT”, the JavaScript Information Visualization Toolkit. Its creator, Nicolas Garcia Belmonte, has recently implemented a number of new features and has created a tutorial, some examples, and some documentation to describe them.

The JavaScript Infovis Toolkit is a JS Information Visualization library that includes radial layout of trees with animations, Treemaps, Hyperbolic Trees and Spacetrees…

One of the most challenging features I wanted to add to these visualizations was the possibility of dealing with mutable data. This way visualizations would also be useful to show how data changes over time, and updates to this data would be translated into smooth animations from one state of the graph to another.

The user could also interact at a deeper level with the visualizations, not only exploring the data, but also altering it, making updates to the information and seeing the results in real time.

Nicolas has created two “real-world” examples to show off this new ability to mutate the graph live:

Example One: Linux Module Dependency Visualizer

It uses the RGraph visualization with the morphing operation to show dependencies between different modules you might find with the apt-get tool. When clicking on a node you’ll set this node as root. Then the graph will perform a second animation, updating the dependencies for the new centered module. Many details about the package are also provided under the Details toggler. You can also go to previous visited modules by using the History toggler.

The accompanying blog entry to this example shows how both the client- and server-side code was implemented, making it interesting indeed.

Example Two: Visualizing relations between artists and bands dynamically

Building on a previous example, this new revision adds a “second animation [that] will take place [when clicking on a node], morphing the tree into the new node’s perspective.”

It’s still an alpha release, but it’s already in the wild.

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

Edward Tufte has long had a following of fans in the field of information visualizations. Among his interesting taxonomy of visualization types is the “Sparkline“, which he describes as “data-intense, design-simple, word-sized graphics”.

While Tufte originally suggested that computer displays are too low-resolution to effectively make use of Sparklines (vs. printed page), James Dempster pointed us to some work the folks at Splunk have done to join a long line of folks who have given it a go anyway.

The resulting jQuery plug-in is really nice. Now if only they had the ability to overlay two line graphs over the same area using a transparent fill… ;-)

(Oh, and there’s also a simple Sparkline generator for Google Charts over at style.org.)

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.