Dev411 Blog: Category ajax

Online Dojo JavaScript Compressor

2006-07-28T12:14:00-05:00

I just put together an online JavaScript Compressor interface to Dojo Toolkit's JavaScript Compressor, custom_rhino.jar. The JavaScript Compressor is used in the final stage of the Dojo Toolkit build process so gets a lot of use. Although there is already an online version, ShrinkSafe, I put another version together because:

It would be nice to have a web app that makes custom Dojo builds people don't have to install the JDK and ant to get a custom Dojo build. This is the primary reason and the compressor is a first step in that direction.
There have been some reports that the JS produced by ShrinkSafe doesn't work (maybe it's using an outdated custom_rhino.jar?). I want an Dojo-based online system to use myself.
It's nice to have more Dojo, Prototype and Scriptaculous integration tests. I used the client code from ShrinkSafe which uses Dojo to add additional file and do Drag-and-Drop along with the Lucid theme which relies on Prototype and Scriptaculous. I learned that dojo.js 0.3.1 needs to be loaded before scriptaculous.js 1.6.1 or Scriptaculous will break Dojo (I updated the Dojo and Prototype Together article). My minimal use of the Lucid theme actually doesn't need scriptaculous.js so I can get away with loading just dojo.js 0.3.1, prototype.js 1.5.0 rc0, effects.js (part of Scriptaculous 1.6.1) and lucid.js. lucid.js is part of the Lucid theme.

The JavaScript compressor eats its own dogfood and uses prototype.js, effects.js and lucid.js compressed into a single-line, single file. Here are the compression sizes and ratios for the files. Generally you save about 30%.

script	uncompressed	compressed multiline	ratio	compressed single line	ratio
prototype.js	55,149	38,696	70%	37,154	67%
effects.js	32,908	23,244	71%	22,527	68%
lucid.js	7,253	4,917	68%	4,741	65%
All files	95,310	67,570	71%	65,137	68%

A number of people are using JavaScriptCompressor.com which is running Dean Edwards' .NET JavaScript compression code. This can be used after Dojo's compressor for even more compression.

Catalyst - Customizing the view to stop IE from caching JSON

2006-07-25T10:49:00-05:00

Often times you'll want to customize your response specific to the View being used, e.g. setting extra headers. This can be done directly in your View class by creating a process method. All View base classes have a process method defined in Catalyst::View that gets called at rendering time. By adding a process method in your subclass and redispatching to the parent you can do some preliminary processing.

One use is preventing IE from caching JSON responses by setting the Cache-Control and Pragma HTTP response headers. You can do this in the application's JSON view as follows:

package MyApp::View::JSON;
use strict; use warnings;
use base qw/Catalyst::View::JSON/;

sub process {
  my $self = shift;
  my $c = $_[0];
  $c->res->header( 'Cache-Control' =>
    'no-store, no-cache, must-revalidate,'.
    'post-check=0, pre-check=0, max-age=0'
  );
  $c->res->header( 'Pragma' => 'no-cache' );
  $c->res->header( 'Expires' => 'Thu, 01 Jan 1970 00:00:00 GMT' );
  $self->NEXT::process(@_);
}

1;

Your process method will get called, set it's response headers and then use NEXT to call C::V::JSON's process method.

Yahoo! UI (YUI) cheat sheets as wallpaper

2006-07-25T03:12:00-05:00

Yahoo! provides a number of cheat sheets for their YUI library widgets however these are in PDF format and not usable as wallpaper. PDF is great as a transport format because you can provide one version for everyone, however transforming it makes it more appealing for actual use. I prefer cheat sheets in standard image formats that can used as wallpaper, espcially useful with virtual desktops.

Here are the YUI 0.11 cheat sheets converted to PNG images of various sizes. Let me know if any other sizes would be useful.

Animation	1400x1050 1280x960 1165x900 1024x768
Calendar	1400x1050 1280x960 1165x900 1024x768
Connection Manager	1400x1050 1280x960 1165x900 1024x768
Dom Collection	1400x1050 1280x960 1165x900 1024x768
Drag & Drop	1400x1050 1280x960 1165x900 1024x768
Event Utility & Custom Event	1400x1050 1280x960 1165x900 1024x768
Logger	1400x1050 1280x960 1165x900 1024x768
Slider	1400x1050 1280x960 1165x900 1024x768
TreeView	1400x1050 1280x960 1165x900 1024x768

JSON XSS exploit: don't use text/html

2006-07-24T20:40:00-05:00

Jim Ley reports on the Google JSON XSS exploit with example code and screen shots of stealing information from the AdSense site. The moral of the story is don't use text/html for the MIME type when returning JSON, use application/json which is an IETF standard (RFC 4627) now. Most browsers should handle application/json fine, however Opera may have problems and you may want to use application/x-javascript for that. Something to remember even if your AJAX code/library doesn't care about the MIME type returned by the server, e.g. Dojo.

If you are using Catalyst and Catalyst::View::JSON, your JSON response will automatically be set to application/json for all user agents except Opera (which gets application/x-javascript) so you're already safe(r).

Prototype's future in Rails

2006-07-20T17:22:00-05:00

The future of Prototype (the JavaScript AJAX library), both as a stand-alone library and as a part of Rails, is being discussed by the community on the rails-spinoffs list. The primary concerns appear to be:

Prototype is driven by one person who hasn't been very active on the list. Some patches are integrated but often without communication
it is difficult for others to contribute
there is no visibility into the roadmap for prototype
prototype is "falling behind" relative to other libraries

The one person vs. community aspect of the discussion reminds me of Red Hat rebuilds. When Red Hat stopped distributing free binaries, a number of projects took advantage of GPL and started providing free rebuild binaries. At first, White Box Enterprise Linux (WBEL) was the most popular and wide-spread rebuild but it was maintained by one person who occasionally got busy. It was eventually overtaken by CentOS which is maintained by a community.

For now, Prototype will remain popular because it comes bundled with Rails and is the basis for RJS and Scriptaculous. Thomas Fuchs has come out and said, "script.aculo.us will always depend on Prototype". Still, I wonder if community maintenance isn't a better way to go for something that's relied on by so many people. Some are even concerned that Rails itself will become less viable if it continues to attach itself to Prototype and the project management doesn't change.

You can follow the thread by going to the list archives page and looking for the subject name "Documenting Prototype...". Greg Hill's post seems like a reasonable place to start.

Autocomplete Survey

2006-07-17T23:15:00-05:00

Here are some screen shots of various autocomplete effects in action to show what people are doing. The images and names above the images have links to the relevant sites with the domain name shown. I'll add more screen shots here as I get them. Let me know if there are any other toolkits demos or interesting implementations.

Here are some observations:

All of the screen shots and links are for toolkits except for Google which is just shown as an example.
The jQuery and Scriptaculous demos do not automatically display "autocomplete" text in the input element.
All of the demos, except Dojo, include text that will end up in the input field as well as extra display text that will not.
Where both simple and customized demos are available, the customized one is used for the screen shot.
Del.icio.us also has nice variable horizontal location/width autocomplete for tags that I don't have a screen shot for atm. Gmail also has a nice autocomplete that isn't shown.

The observations are just for the particular demos available. The libraries may have the ability to be configured in additional ways.

Dojo (dojotoolkit.org)

(fullsize screen shot)

jQuery (jquery.com)

(fullsize screen shot)

Yahoo UI (yahoo.com)

(fullsize screen shot)

Google (google.com)

(fullsize screen shot)

Scriptaculous (script.aculo.us)

(fullsize screen shot)

NOTE: The jQuery screen shot has been edited to size it better from the demo page: (a) the number of results was reduced and (b) the width has been reduced because there's a lot of blank space in the demo. The original jQuery screen shot is also available.

UPDATE: CAPXOUS has an interesting paged autocomplete variation which adds Next and Prev links when applicable. The one minor issue I ran into when using this is that it would switch location (above/below the input) if it was near a browser edge and the number of items changed as shown below. I found this a bit disconcerting. I wonder if there's a way to making it always used the side for the larger list? CAPXOUS can also show info that's searched on but not shown but this was less interesting than the paging. One final note, unlike the other JS libraries listed above which are free open source software (FOSS), CAPXOUS is commecial requires a license fee. Pretty interesting idea.

CAPXOUS (capxious.com)

(fullsize screen shot)

Dojo - dojo.addOnLoad vs. body onload and window.onload

2006-07-13T23:57:00-05:00

When using Dojo Toolkit, you should avoid using <body onload="..."> or window.onload (make sure to check external scripts you use as well). This is because Dojo does it's own window.onload and doing it yourself can interfere with Dojo's initialization routines (including DOM rewriting). Dojo has provided dojo.addOnLoad for this which allows you to load functions after Dojo has finished its own initilization.

To use dojo.addOnLoad you need to pass a function which can be in either of the following formats:

dojo.addOnLoad( myinit );

dojo.addOnLoad( function() { myinit(); });

You cannot, however, use a function call like the following since Dojo is expecting an object, not a function call.

dojo.addOnLoad( myinit() );

I discussed using dojo.addOnLoad in a previous entry about setting Dojo's combobox default value but thought it worthwhile to have a separate entry since this issue continues to come up.

Should there be a standard X-Ajax-Engine request header?

2006-06-30T12:49:00-05:00

A little while ago I was looking at JSON and Catalyst::View::JSON (a server-side library to provide some JSON repsonse magic for Catalyst) and I discovered that AJAX libraries auto-eval JSON differently, Dojo looks in the response body and Prototype looks in the X-JSON header (read about X-JSON problems with IE 6). This got me thinking that there's no standard way for the server to tell what kind of AJAX library is making the request. Prototype sets the X-Requested-With and X-Prototype-Version as:

var requestHeaders =
  ['X-Requested-With', XMLHttpRequest',
   'X-Prototype-Version', Prototype.Version,

For Dojo, some people are manually sending a request header along the lines of isDojo:true. MochiKit doesn't currently send an identifier.

I tend to prefer a bit more information such as the library version. Does it make sense for AJAX libraries to send a standard User-Agent along the lines of X-XMLHttpRequest-User-Agent (X-AJAX-User-Agent is shorter but may not be as correct; subsequent to the initial post, a discussion with Alex Russell generated the X-Ajax-Engine name which has been incorporated below). Something shorter is preferable but this is just an initial proposal. It would also remove the need for Prototype's separate X-Requested-With header since having X-Ajax-Engine set at all would indicate XMLHttpRequest. The format could follow the one established for User-Agent:

X-Ajax-Engine: <library_name>/<library_version>

This can be done manually with Dojo, MochiKit and Prototype as follows:

// in a Dojo.io.bind call:
headers: {
 'X-Ajax-Engine':'Dojo/'+dojo.version
}

// for MochiKit:
req.setRequestHeader(
  'X-Ajax-Engine',
  'MochiKit/'+MochiKit.Async.VERSION
)

// in a Prototype AJAX.Request call:
requestHeaders: [
  'X-Ajax-Engine',
  'Prototype/'+Prototype.Version
]

Optional information could be added in parenthesis afterwards, e.g. Dojo Toolkit could include the edition name or something along the lines of "Custom Build" like (I'm not sure if other libraries have a reason to do this):

X-Ajax-Engine: Dojo/0.3.1 (BrowserIO)

If client libraries started using this or something similar, server-side identification could start (attempting to) depend on something that was standardized. Standardization can even be proposed as an addition to the W3C's XMLHttpRequest efforts. I think standardization would be great because it will probably happen eventually and for now it would make server-side identification more reliable.

UPDATE 1: Less than a week after I posted this, a related issue came up on the MochiKit Google Group involving adding a X-MochiKit-Version header to mimic X-Prototype-Version. I put in a word for standardization and after discussing this with Alex Russell (see below) posted back to the group. Seems like we may get a defacto standardization on X-Ajax-Engine which would be nice.

UPDATE 2: I spoke to Alex Russell of Dojo Toolkit about this and he thought this is a good idea. Apparently if you set sendTransport in dojo.io.bind, an identifier (but not version number) will get sent, however it seems not many people know about this. We discussed shorter names and Alex came up with X-Ajax-Engine. He mentioned he could bring this up at the OpenAjax Alliance.

Dojo - Setting the ComboBox Default Value

2006-06-14T03:39:00-05:00

Dojo Toolkit's ComboBox doesn't take a default value but one can be written in using JavaScript. The default value in the ComboBox dojoType is lost during onLoad when the dojoType widget is rendered. To get around this we can use JavaScript to fill in the value during dojo.addOnLoad. Here's the relevant JavaScript:

function init() {
  var mycombobox = dojo.widget.byId('mycombobox');
  mycombobox.textInputNode.value = 'Seattle';
}

// method 1
dojo.addOnLoad( init );

// method 2
dojo.addOnLoad( function() {
  init()
} )

// won't work b/c you want to send an object
// not call a function
dojo.addOnLoad( init() );

The HTML:

<input dojoType="ComboBox"
  id="mycombobox"
  value="this should never be seen - it is replaced!"
  dataUrl="comboBoxData.js" style="width: 300px;" name="foo.bar"
  onValueChanged="setVal2"
>

A more detailed example of this technique is available on the wiki at Dojo Toolkit: Setting the Combobox Default Value.

Dojo and Prototype Together

2006-06-13T21:31:00-05:00

I just wanted to report and let everyone know with Prototype 1.5.x, Dojo Toolkit and Prototype should now be interoperable. Earlier versions of prototype.js extended the JavaScript Object prototype that would break third-party JavaScript but this is no longer being done. A few people, including myself, have been using them together without any problems. The prototype website still offers 1.4.0 as the current version, however 1.5.0 rc0 is included with Scriptaculous 1.6.1. I'm currently using prototype 1.5.0 rc0 with Dojo 0.3.1 and Scriptaculous 1.5 rc4. Although Scriptaculous 1.6.1 is available, it breaks autocomplete for me and I haven't had time to track down what changed yet. Hopefully soon.

UPDATE: The Scriptaculous 1.6.1 issue has been reported to RoR as ticket #5673. This has since been fixed with Scriptaculous 1.6.2. I'm now using Dojo 0.3.1, Prototype 1.5.0 rc0 and Scriptaculous 1.6.2.

UPDATE 2: When running dojo.js and scriptaculous.js together, make sure you load dojo.js first. Loading scriptaculous.js first will cause Dojo to fail.