samaxes

Although I’m not a big fan of the Dojo Toolkit, I’m impressed with the the Dojo Offline Toolkit.

I’m confident that this will greatly improve the way some actual web applications work.

What is the Dojo Offline Toolkit?

Dojo Offline is a free, open source toolkit that makes it easy for web applications to work offline. It consists of two pieces: a JavaScript library bundled with your web page and a small (~300K) cross-platform, cross-browser download that helps to cache your web application’s user-interface for use offline.

How Dojo Offline Works?

Dojo Offline uses a very small, standard web proxy that runs locally. Web proxies are perfect; they speak standard HTTP/1.1 between a web browser and a server, caching files that wish to be cached for later access without hitting the network. Many companies run a web proxy on their networks, caching commonly accessed pages for later access; why can’t this web proxy run on a user’s local machine, caching a web application’s UI for offline access? A web server can simply turn on standard HTTP/1.1 caching headers on its user-interface files, which the proxy dutifully caches. If the browser comes up but the network is down, the local web proxy will simply hand back its cached UI files. Even better, the proxy will automatically update any of its cached files if they have been updated, based on their caching headers, which means the UI gains auto-update for free — no new standards are needed.

How do we configure the web browser to talk to our local web proxy? We use a standard from the late nineties not known by many but which has deep and mature support in all browsers called Proxy AutoConfiguration (PAC). A PAC file is a small bit of JavaScript that is invoked on each browser request. This JavaScript can decide how to resolve the address, either by directly talking to the web site or by using a proxy. For Dojo Offline, we only want to talk to the local proxy and cache files for Dojo Offline web applications, not for all web sites so that that we don’t fill up our hard drive. Our PAC file will therefore talk to the local web proxy for any domain names that want to work offline, and will ignore the proxy for all other addresses; this will be a simple JavaScript if/else statement in the PAC file. We programatically register our PAC file for a user’s browser. This PAC file is actually generated dynamically by the local Dojo Offline proxy.

How does a web application add itself to the PAC file so it can work offline? We have to be very careful here. We don’t want to create an attack vector to the user’s local computer by having the web application “talk” to localhost, such as “http://localhost:1234/add-web-app?url=mywebapp.com” or make it possible for one web application to spoof another one and have it be added to the PAC file if it doesn’t want to be added. The entire focus of security for Dojo Offline is to keep the surface area of trust as narrow and small as possible, constraining privilege to just the small web proxy, which only runs on the loopback address and never touches the real network — everything else must use standard domain names, forcing them into the browser’s standard, restricted web privilege level. Further, the Dojo Offline Toolkit’s proxy is completely generic and does not have to be tailored for individual applications.

Dojo Offline’s PAC file comes bundled with a single, magical bootstrap domain name initially, “offline.dojo.web.app,” that a web application can invoke to add itself to the PAC file. The PAC file routes any request for this domain to the local proxy, and the Dojo Offline proxy checks the referer (sic) header for the domain name to be added offline. Normally the referer field can be spoofed, but there is no way for a web application to spoof the referer field from inside the web browser. The predefined offline.dojo.web.app domain name also exposes other services a web application can use, such as knowing whether it is on- or off-line. Access to these services is mediated by a thin, easy-to-use Dojo Offline JavaScript API, bundled with the web application itself.

The web browser does not know the difference between whether you are on- or off-line, since the proxy serves up the UI either way. Dojo Storage can save hundreds of K or megabytes of application-level data, and is keyed off of the domain name for security; Dojo Storage is therefore “tricked” into not knowing the difference and is therefore accessible either way with the same data store. Applications can use this persistent, megabyte-capable store for all offline data needs, accessing the same information whether you are on- or off-line.

The last step is to wrap the Dojo Offline Toolkit into a small installer for each target platform, and to have it start up silently on system startup. The download size will be only 100 to 300K, making it extremely easy to download and try; an uninstaller will also exist for each platform, bundled with the download. Everything is automated, hands-off, and easy.

Try out the Moxie demo, and download the Dojo Offline SDK.

Other frameworks implementing offline functionality

• Apollo - Proprietary framework by Adobe that enables you to create web applications that work seamlessly of whether a user is connected to Internet or not.
• Dekoh - Pretty much the same but open source and cross platform (written in Java).
• Slingshot - Offline functionality to Rails apps.

With the release of Internet Explorer 7 (IE 7), web developers once again need to test multiple versions of IE. Unlike other browsers like FireFox, IE is a system component for the Windows operating system. This makes running multiple versions side-by-side very difficult.

Thanks to Yousif Al Saif’s Multiple IE installer it’s possible to run Internet Explorer in standalone mode without having to over-write previous versions.

Ajaxian has published their second annual Ajaxian.com survey.

The first three by categories are:

Most Popular Ajax Frameworks

1. Prototype - 43%
2. Script.aculo.us - 33%
3. Dojo - 19%

Most Popular Ajax Platforms

1. PHP - 50%
2. Java - 37%
3. .NET - 16%

Read the original article here.

Update from Joe Walker’s Blog (with a Java perspective):

Most Popular Java / Ajax Frameworks

1. DWR - 53%
2. GWT - 15%
3. AjaxTags - 7%

Today I stumbled on an article from 5ThirtyOne about an IE7 Javascript library simply called IE7.

IE7 is a JavaScript library to make IE behave like a standards-compliant browser. It fixes many CSS issues and makes transparent PNG work correctly under IE5 and IE6

Impressive…

I’ve already commented in a previous post about the previous post about the Google Web Toolkit (GWT). The Google Web Toolkit was the talk of JavaOne 2006, offering developers a way to create Ajax applications by writing Java and having the toolkit generate the client-side JavaScript, which can call back to Java servlets through an RPC-like call.

Robert Cooper offers an initial tutorial to get you up and running with GWT.

Google has released Google Web Toolkit (GWT), a code generation framework that lets you code Ajax apps in pure Java.

Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translates your Java application to browser-compliant JavaScript and HTML.

Here’s the GWT development cycle:

1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
2. Use GWT’s Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.

A widget like tree has methods to manipulate the structure (e.g. addItem()) and event handlers (e.g. addFocusListener). Here’s how a tree is created:

CSS Style Rules

1
2
3

.gwt-Tree { the tree itself }
.gwt-Tree .gwt-TreeItem { a tree item }
.gwt-Tree .gwt-TreeItem-selected { a selected tree item }

Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class TreeExample implements EntryPoint {
 
    public void onModuleLoad() {
        // Create a tree with a few items in it.
        TreeItem root = new TreeItem("root");
        root.addItem("item0");
        root.addItem("item1");
        root.addItem("item2");
 
        Tree t = new Tree();
        t.addItem(root);
 
        // Add it to the root panel.
        RootPanel.get().add(t);
    }
}

Brendan Eich, creator of JavaScript, give a keynote at The Ajax Experience.

Ajaxian have placed the presentation online so everyone can read up on some of the thoughts and discussion on JavaScript 2 and more.

Here we got to hear from the mouth of someone deep into the ECMA process about what we are going to see in JavaScript 2 and importantly why:

Motivation for JS2

• Fix problems in JS1 that bug people daily
• A type system to enforce invariants
  • instead of writing/debugging lots of value-checking code
  • optional annotations, an extension to JS1
• Programming in the large
  • Package system
  • Visibility qualifiers (namespaces, private internal public)
  • Optional static type checking
• Support bootstrapping and metaprogramming
  • Self-host most of the standard objects
  • Self-host compiler front end and type checker
  • Reduce need for future ECMA Editions

As Brendan flicked through these slides, I couldn’t help buy realise how important the decisions are. These changes are probably going to profoundly effect all of our lives in the near future.

Coverage on the talk on InfoWorld

Max Kiesler as posted in his site an article with 60 more AJAX tutorials.

These examples and how-to’s represent the best tutorials that I’ve personally used or otherwise had the opportunity to work with out of the overall group. This post is intended for individuals who learn best by example. Most of the listed tutorials come complete with instructions and source code.

Read the 60 More AJAX Tutorials full article.

When you’re a web developer, you always keep running into annoying Internet Explorer bugs, so you need to hack your way around. Now with the IE7 out, a lot of the old CSS hacks don’t work anymore, and those that do still work, can’t be relied on to work in the future.

IE has a feature, called conditional comments, which could help us. As a hack it’s quite useful. IE 7 will support this too, and it even allows you to detect different versions of IE.

Here’s an example:

1
2
3
4
5

<!--[if lte IE 6]>
    <style type="text/css">
        @import "ie_hacks.css";
    </style>
<![endif]-->

[if lte IE 6] means “if less than or equal to IE 6″. Other possibilities are:

[if IE]

if Internet Explorer

[if gte IE 5]

if greater than or equal to IE 5

[if lte IE 5]

if less than or equal to IE 5

[if IE 6]

if Internet Explorer 6

[if IE 5.5]

will work too,

[if IE 7.0b]

as will this for IE 7 beta.

Max Kiesler has posted on his site, a listing of 50 different Ajax toolkits and frameworks, and a listing of 30 different AJAX Tutorials.

1. Round-up of 50 AJAX Toolkits and Frameworks
2. Round-up of 30 AJAX Tutorials

Of course, the lists are by no means complete, but they do include not only the “big names” but also several of the smaller, lighter libraries the web has to offer.