sorted by: recent | see : popular

Content Tagged with Page + dojo

We heard from Will of the Psych Desktop project as he ran across our coverage of other Web desktop apps. He shared with us his project that is part of the Dojo Foundation which you can check out here.

He had some good thoughts, so I thought I would pass them along below:

Psych Desktop is an open source web desktop licensed under the AFL. We're a part of the Dojo Foundation, and have been around for around two years I believe. We're going to rename the project as Lucid when we finish our new site.

Anyways, there are two main ideas behind Lucid. The first is that we aren't just building a clone of a desktop environment, but rather a desktop that was built for the web. For example, in 1.1 we plan on providing an alternate UI made for mobile devices such as an iPhone. Another example of what we want to accomplish would be a photo manager that would easily allow you to publish photos to a public photo gallery. We also want to do the typical things, like a word processor and email, but that's not the main idea behind the desktop.

The second idea behind it is that we should provide a nice, clean set of APIs for developers to use in their apps. For example, we've got a Registry that is based off of a dojo.data store, so you can plug it directly into a dojox.grid.DataGrid, and you instantly have an editable grid that writes back to the store. Another neat API is the crosstalk API, which allows intercommunication between users. The Messenger app is using this. There's also a sound API that can be used to playback audio. The apps are written in javascript, and don't require any server-side code at all. And of course, there's also a filesystem.

Right now we're in beta, but we're coming close to our 1.0 release. There's still a bit of work to be done, but it's stable enough for developers to start playing with it. 1.1 is going to be a lot more innovative, but I think 1.0 will be good starting grounds for our expedition.

It is cool to see the Will is passionate about the area and is "in it for the long term."

Voting has started in Dojo land to take in John Resig's Sizzle next-gem CSS selector engine.

This is incredibly exciting, as it shows how Ajax libraries are working together more and more. Instead of reinventing the wheel in different ways for each project, is it possible to find some core pieces that can be nicely shared? Of course, if our world was nicer and we could share code by linking in a nice way maybe this would happen more.

As I mentioned in my thanksgiving note, the work that the Ajax library developers do is hugely important and impactful, and having them work together can only be great news.

Take a look at this public email to the Dojo Foundation on the vote:

Overview

The Sizzle project is a JavaScript library for performing selections
across a DOM tree using CSS selectors. The library is designed to be
standalone (have no external dependencies), lightweight, fast, and
extensible. This culminates in a library that is perfectly suited for
integration into other libraries. While it's feasible that a developer
may use Sizzle directly the target audience for it is other library
authors.

The code for Sizzle can be found in the following Git repository:
http://github.com/jeresig/sizzle/tree/master

All of the code for the project has been written by John Resig and is
released under an MIT license. There are some patches pending from
some other contributors (namely Prototype).

Right now the following libraries are adopting or are looking to adopt
Sizzle as their primary CSS selector engine:

• jQuery
• Prototype
• Dojo
• MochiKit
• TinyMCE
• PURE
• reglib
• Haxe

It's likely that Sizzle will become the unified engine behind a
majority of the JavaScript libraries on the market (if not in numbers
then certainly in market share).

The project is owned by John Resig who will serve as BDFL/Project lead
if the project is accepted. There is no formal voting process, as of
yet, but it's likely that one will come about, considering the number of
projects using the codebase.

If the project is accepted to the foundation then all contributors to
the project will be required to have a CLA and follow the policies of
the Dojo foundation.

It's very likely that Sizzle will eventually expand into other areas
of JavaScript libraries (such as DOM manipulation and event binding).

That last line excites me too! It is interesting to see this happen in the Dojo Foundation. Remember, Dojo was founded out of toolkits coming together to aggregate forces. Kudos to everyone involved, and good luck!

With the rich JavaScript library ecosystem, it can be extremely difficult to make informed decisions when choosing which libraries to use for your own projects. Because no one has time to analyze each library in detail themselves, such decisions are usually made by getting a feel for what the "street" thinks and making the safe choice. Unfortunately, sometimes the word on the street doesn't map to reality as the echo chamber arrives at a false consensus.

Dylan Schiemann recently wrote a blog entry to debunk some of the inaccuracies he's seen crop up about Dojo, the toolkit he co-founded, addressing such points as:

• Dojo is Undocumented
• Dojo is Slow
• Dojo is Bloated, Larger and More Complex than Prototype, jQuery, MooTools, YUI, etc.
• Dojo Requires Java
• Dojo is Verbose and is "Java for JavaScript"
• Dojo is only Useful for Enterprise Apps and not for Small Sites or Blogs
• Dojo is Just About Widgets
• Interest in Dojo is Waning
• Dojo is Ugly

It's a great high-level update on the state of Dojo today.

Bill Higgins of IBM Rational has written up some thoughts on componentization and packaging for Ajax applications based on work that his team did on the Rational Jazz platform.

Some of what he built was:

• A nice component model based on OSGi bundles and the Dojo module system
• Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files - i.e. no developer effort required for fast code loading other than writing good code
• Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
• A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component)
• Dynamic, transparent loading of missing code in response to a user gesture that required it

He then goes on to explain the architecture of reusable building blocks, and a realization:

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library.

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.

Any kind of heavy packaging systems haven't done hugely well in the Ajax community as a-whole, but there is a huge problem with components and being able to reuse them. The fact that someone builds a great jQuery plugin, that then gets ported to Prototype and Dojo and .... is frustrating (one example, it happens N times, with the original framework changing).

I have seen some of the great applications that SitePen produces, but unfortunately too many of them are for companies behind the firewalls.

It is great to see Sensei a really compelling Dojo application that SitePen wrote for their training class. This isn't one of those simple training examples that you normally get though. This says quality.

Revin Guillen explains:

When conducting Dojo training courses, we’ve found it to be very valuable to go beyond simple code snippets to demonstrate APIs, patterns, and other key concepts. Snippets and demos are useful, but they often lack a very important quality: context. Nothing beats having a full application in front of you—with code available to read and modify as you learn the ropes—so we built the Dojo Sensei Reader, a rich, powerful RSS reader realized as a single-page web application.

We designed Sensei specifically for training sessions. We wanted something that demonstrates the major areas of functionality Dojo offers, but as a single cohesive application rather than a collection of unrelated demos. We wanted something small enough that training groups could easily grasp the entire codebase, yet large enough to be worth using as a real-world application. We wanted something that shows the development process from start to finish, to demonstrate the level of polish you can achieve in a Dojo-based application. Beautiful as well as functional, it does all of this while providing a great, fast user experience.

One of the beautiful things about Sensei is that it proves that you don’t have to sacrifice maintainability to build a fast application. One key goal in our development process was to create an easy way for training groups to introspect the code, follow the app as it works, and even modify or augment its behavior at run-time by swapping code in and out. To deliver on this, we designed and integrated what we call Blox, a small JavaScript package with the power to make it all possible (it’s Sensei’s flux capacitor; we’ll cover it later). The result is a codebase that is very easy to work with but incurs negligible performance impact for its trouble.

Check out the screencast to see it in action

Shane O'Sullivan has built a nice search mashup experience called Chofter. It uses all things Dojo, including:

• Layouts, Dialogs, Menus and ContentPanes for the user interface.
• dojo.data and dojo.rpc for data transfer.
• dojox.dtl (Django Templating Library) for transforming search data into visuals.
• dojo.fx and FisheyeLite for eye candy

Kris Zyp has created OfflineRest, a new module in Dojo 1.2 that allows for a simple offline pattern to building your application.

Dojo 1.2’s new dojox.rpc.OfflineRest module automates the local storage of data and synchronization by leveraging the Dojo Data and REST abstractions. The OfflineRest module augments the JsonRest service in Dojo such that requests are cached in local storage for offline access, and modification requests (put, post, and delete) modify the cache and are recorded for delivery to the server; immediately if online, otherwise when connectivity is restored. Furthermore, JsonRest is the core engine used by JsonRestStore. Consequently, you can simply use the standard Dojo Data API with the JsonRestStore and effortlessly add offline capability with no modifications to your data interaction code. The underlying Rest service automates the handling of caching, storing data locally, and syncing changes. In addition the new OfflineRest module has no dependency on plugins, but rather progressively utilizes offline features that are available, while still operating properly on legacy browsers without offline support.

He has a demo that involves a CRUD system for hiking trails which interestingly asked me for Gears permission, even though it appears that OfflineRest doesn't abstract on top of both Gears and the emerging storage standard, which is something I would like to see, to extend the reach.

Matthew Russell is blogging and screencasting work from Dojo: The Definitive Guide and has put together a piece on a simple, degradable reflection widget using dojo.gfx:

Reflection has been in vogue for a while now in user interfaces, and it wasn’t long ago that I saw a headline about a JavaScript library that streamlined a number of useful effects such as reflection — but alas, without the benefit of Dojo. Well, being the Dojo fanboy that I am, I immediately started to ponder how to accomplish some of these same effects using the dojox.gfx module, and a couple of hours later, I had prototyped a nice, degradable widget that seemed to do the job. By the way, that’s one of the things I love so much about Dojo: once you have a reasonable grip on it, you seldom, if ever, have to look somewhere else. More times than not, a great deal of your work is already done for you, and you just have to connect some of the dots. Remember: it’s all about the frameworks

But there’s always a catch: in this case it’s that IE users must have Silverlight installed for the widget to work; otherwise, it degrades back to the plain image. The reason is that VML, IE’s default gfx renderer, doesn’t support transparency in gradients. No transparent gradient, no nice fade out effect. Likewise, if JavaScript is not available (honestly, who does that?), it degrades down to the bare image. If you didn’t already know, the gfx module exposes an API that works across browsers by using whatever drawing engine is available. At the moment, renderers are available for canvas, VML, SVG, and Silverlight. That pretty much covers it. Adding support for another one should be straightforward: follow the API guidlines and write it.

The Silverlight requirement is interesting, isn't there a way to use IE behaviours to do a transparent gradient?

Watch the screencast to see it all in action.

Tom Trenka has a fantastic post on custom fonts with dojo.gfx that shows the SVG font definition implementation.

Part one of the article deals with painful, practical issues around the licensing of fonts. Tom discusses the various technical options out there, and then gets to the solution:

In general, the issues surrounding font usage have to do with the ability for someone to visit a web site, grab a specific file, and be able to reuse it without paying for a legitimate copy within any of the most commonly used programs (such as Office). Because of this concern, both the EOT and sIFR techniques work–because the fonts are embedded in a form that is not reusable in a common way.

One approach: the SVG Font Specification

Similarly, the SVG Font specification allows for the same concept—by working with a specific font definition, especially one that can be customized for the specific usage, the spec avoids most of the prickly issues surrounding licensing.

SVG fonts are relatively simple in concept; within the <defs> element, you define the main specifications of a font, and then you include specific glyph definitions. Optionally, you can include character-specific kerning information (the space between letters); some fonts include this type of hinting, and the SVG specification supports it.

Very impressive. If you are a typography wonk, then you have probably watched Helvetica: The Movie: