dojo iconscriptaculous iconprototype icon

Online Dojo JavaScript Compressor

Posted in , , , Fri, 28 Jul 2006 17:14:00 GMT

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.

del.icio.us:Online Dojo JavaScript Compressor digg:Online Dojo JavaScript Compressor reddit:Online Dojo JavaScript Compressor spurl:Online Dojo JavaScript Compressor wists:Online Dojo JavaScript Compressor simpy:Online Dojo JavaScript Compressor newsvine:Online Dojo JavaScript Compressor blinklist:Online Dojo JavaScript Compressor furl:Online Dojo JavaScript Compressor fark:Online Dojo JavaScript Compressor blogmarks:Online Dojo JavaScript Compressor Y!:Online Dojo JavaScript Compressor smarking:Online Dojo JavaScript Compressor magnolia:Online Dojo JavaScript Compressor segnalo:Online Dojo JavaScript Compressor

5 comments

rails iconscriptaculous iconprototype icon

Prototype's future in Rails

Posted in , , , Thu, 20 Jul 2006 22:22:00 GMT

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:

Read more...
del.icio.us:Prototype's future in Rails digg:Prototype's future in Rails reddit:Prototype's future in Rails spurl:Prototype's future in Rails wists:Prototype's future in Rails simpy:Prototype's future in Rails newsvine:Prototype's future in Rails blinklist:Prototype's future in Rails furl:Prototype's future in Rails fark:Prototype's future in Rails blogmarks:Prototype's future in Rails Y!:Prototype's future in Rails smarking:Prototype's future in Rails magnolia:Prototype's future in Rails segnalo:Prototype's future in Rails

4 comments

mochikit icondojo iconprototype icon

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

Posted in , , , Fri, 30 Jun 2006 17:49:00 GMT

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.

del.icio.us:Should there be a standard X-Ajax-Engine request header? digg:Should there be a standard X-Ajax-Engine request header? reddit:Should there be a standard X-Ajax-Engine request header? spurl:Should there be a standard X-Ajax-Engine request header? wists:Should there be a standard X-Ajax-Engine request header? simpy:Should there be a standard X-Ajax-Engine request header? newsvine:Should there be a standard X-Ajax-Engine request header? blinklist:Should there be a standard X-Ajax-Engine request header? furl:Should there be a standard X-Ajax-Engine request header? fark:Should there be a standard X-Ajax-Engine request header? blogmarks:Should there be a standard X-Ajax-Engine request header? Y!:Should there be a standard X-Ajax-Engine request header? smarking:Should there be a standard X-Ajax-Engine request header? magnolia:Should there be a standard X-Ajax-Engine request header? segnalo:Should there be a standard X-Ajax-Engine request header?

5 comments

dojo iconscriptaculous iconprototype icon

Dojo and Prototype Together

Posted in , , , , Wed, 14 Jun 2006 02:31:00 GMT

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.

del.icio.us:Dojo and Prototype Together digg:Dojo and Prototype Together reddit:Dojo and Prototype Together spurl:Dojo and Prototype Together wists:Dojo and Prototype Together simpy:Dojo and Prototype Together newsvine:Dojo and Prototype Together blinklist:Dojo and Prototype Together furl:Dojo and Prototype Together fark:Dojo and Prototype Together blogmarks:Dojo and Prototype Together Y!:Dojo and Prototype Together smarking:Dojo and Prototype Together magnolia:Dojo and Prototype Together segnalo:Dojo and Prototype Together

6 comments

catalyst iconperl icontemplatetoolkit iconscriptaculous iconprototype icon

HTML::Prototype - AJAX Without JavaScript

Posted in , , , , , Tue, 06 Jun 2006 01:52:00 GMT

HTML::Prototype is by far the most painless way to get started with AJAX that I've found. Simply put, you do not need to know or write any JavaScript! HTML::Prototype is a Perl module on CPAN that wraps the prototype AJAX library and Script.aculo.us effects library with Perl helper methods so you don't need to write a single line of JavaScript to get some great effects. There are also a number of modules that wrap HTML::Prototype for integration with Catalyst, CGI::Application, Template Toolkit and others.

There are a number of convenient methods such as link_to_remote() and submit_to_remote() that create a link and form button to make an AJAX call and populate the innerHTML of a specified DOM element with the response body. Syntactic sugar to be sure as the JS generated by HTML::Prototype is very simple once you look at it, but the beauty is that you never have to.

To truly appreciate HTML::Prototype you need to use some of Scriptaculous' more advanced widgets such as autocomplete. Sebastian Riedel put together a screencast using Catalyst that demonstrates how easy it is to use. Links to the screencast are available on the Catalyst wiki movies page:

http://dev.catalyst.perl.org/wiki/Movies

Another great thing about having HTML::Prototype generate the JS syntax for you is that you can learn prototype syntax just by View Source. I picked up enough of prototype's JS syntax this way that I haven't looked at the docs yet.

I've recently removed HTML::Prototype from a project in favor of using prototype.js and scriptaculous.js directly and I'm evaluating the Dojo Toolkit but HTML::Prototype let me get started with very effective, painless AJAX functionality. I used it with Catalyst::Plugin::Prototype and thought 'this is how frameworks make you productive.' Thanks to all the contributors.

del.icio.us:HTML::Prototype - AJAX Without JavaScript digg:HTML::Prototype - AJAX Without JavaScript reddit:HTML::Prototype - AJAX Without JavaScript spurl:HTML::Prototype - AJAX Without JavaScript wists:HTML::Prototype - AJAX Without JavaScript simpy:HTML::Prototype - AJAX Without JavaScript newsvine:HTML::Prototype - AJAX Without JavaScript blinklist:HTML::Prototype - AJAX Without JavaScript furl:HTML::Prototype - AJAX Without JavaScript fark:HTML::Prototype - AJAX Without JavaScript blogmarks:HTML::Prototype - AJAX Without JavaScript Y!:HTML::Prototype - AJAX Without JavaScript smarking:HTML::Prototype - AJAX Without JavaScript magnolia:HTML::Prototype - AJAX Without JavaScript segnalo:HTML::Prototype - AJAX Without JavaScript

no comments

json iconie iconprototype icon

Prototype - X-JSON fails on long value in IE

Posted in , , , Thu, 01 Jun 2006 20:14:00 GMT

Unlike Dojo Toolkit and other client-side AJAX libraries that read a JSON object from the response body, prototype.js reads it from the custom X-JSON header. I didn't run into any problems with prototype's approach developing on Firefox but I soon discovered IE 6 has a max header size that will cause prototype 1.5.0 rc0's evalJSON method to silently fail with an unreported [object Error] error. In my case, IE 6 would handle an X-JSON string with length of 138 bytes but would fail with a length of 1659 bytes. Firefox 1.5.0.3 and 1.0.7 worked fine with both strings. I'm not sure what IE 6's exact limit is but the fact there's a limit at all is discouraging IMO.

The argument I've seen for putting the JSON object in X-JSON is that you can put a separate large quanity of HTML in the response body. This design works well when you only have one or zero large quantities of HTML. As soon as you have two, you need to either put them both in the response body using another serialized data notation or put them both in the JSON object and put the JSON object in the response body instead of the X-JSON header. It seems better to simply expect the JSON object in the response body in all cases than in cases when there's only one or zero large return values.

Let's take a look at an example. In the following the one Ajax JSON response can return meta data about the overall response ("Result":"ok") as well as a list of "Posts", say when updating a post list on something like Digg's homepage. Further more a list of "Hot Stories" can simultaneously updated in the same request. Each one of the stories may have a description or overall information that exceeds IE 6's max header length.

{
  "Result":"ok",
  "Posts":[
    {
      "time":1149349580,
      "id":100001,
      "title":"Article 11 title",
      "desc":"Article 11 desc
         (longer than IE header length)",
      "votes":120,
      "comments":5,
      "submitter":"garfield"
    },
    {
      "time":1149349583,
      "id":100002,
      "title":"Article 12 title",
      "desc":"Article 12 desc
         (longer than IE header length)",
      "votes":125,
      "comments":15,
      "submitter":"garfield"
    }
  ],
  "Hot Stories":[
    {
      "time":1149348000,
      "id":1001,
      "title":"Hot Article 1 title",
      "desc":"Hot Article 1 desc
         (longer than IE header length)",
      "votes":1120,
      "comments":115,
      "submitter":"garfield"
    },
    {
      "time":1149349000,
      "id":1002,
      "title":"Hot Article 2 title",
      "desc":"Hot Article 1 desc
         (longer than IE header length)",
      "votes":1120,
      "comments":115,
      "submitter":"garfield"
    }
  ]
}

I understand where having a proprietary X-JSON header and a separate response body is useful however I view those situations as a subset of a more generic, and powerful, use. With more complex return values, putting the JSON object in the response body is ultimately a more flexible and extensible design.

I'll continue to use prototype for now but I'm going to set all my JSON objects in the response body and eval it myself given IE 6's short comings. A bigger concern for me is that I feel Prototype's use of putting the JSON object in X-JSON will encourage inefficient AJAX implementations that end up using more HTTP request/response cycles than necessary. I really hope prototype.js will move their auto-eval feature to operate on the response body due to this problem and to make it more compatible with other JS AJAX libraries at the same time.

del.icio.us:Prototype - X-JSON fails on long value in IE digg:Prototype - X-JSON fails on long value in IE reddit:Prototype - X-JSON fails on long value in IE spurl:Prototype - X-JSON fails on long value in IE wists:Prototype - X-JSON fails on long value in IE simpy:Prototype - X-JSON fails on long value in IE newsvine:Prototype - X-JSON fails on long value in IE blinklist:Prototype - X-JSON fails on long value in IE furl:Prototype - X-JSON fails on long value in IE fark:Prototype - X-JSON fails on long value in IE blogmarks:Prototype - X-JSON fails on long value in IE Y!:Prototype - X-JSON fails on long value in IE smarking:Prototype - X-JSON fails on long value in IE magnolia:Prototype - X-JSON fails on long value in IE segnalo:Prototype - X-JSON fails on long value in IE

8 comments

json iconcatalyst iconperl iconprototype icon

Prototype, JSON and Catalyst

Posted in , , , , Thu, 01 Jun 2006 00:42:00 GMT

I use the prototype.js library (aka prototype) for AJAX and recently moved to using JSON to return multiple elements instead of a single one. I had to rearchitect my client request code and my server code to handle JSON but it's worth it to minimize the number of HTTP requests. I use Catalyst and JSON::Syck which make generating the JSON response on the server-side very easy.

Prototype.js is interesting in that it auto-evals a JSON object that's placed in the X-JSON header instead of the response body like other libaries such as Dojo Toolkit. This allows you to send HTML in the response body but I'm not convinced this is a good implementation since it supports only one HTML fragment in the response body. I think it would be better to simply put the JSON object in the response body and have all the HTML fragments in the JSON object. I just seems cleaner to put all the HTML fragments in JSON instead of fragment 1 in the response body and fragments 2-n in JSON. Although I have the X-JSON header working, I may just move to the more standard JSON in response body approach and eval the JSON string myself. To read the auto-evaled JSON response, the following example expects a JSON associative array and displays the value of the myItem key (more code is available in the wiki link below):

onComplete: function( request, json ) {
    alert( json.myItem );
}

On the server-side, I use the Catalyst framework to set the header and JSON::Syck to transform Perl data structures to JSON. JSON::Syck is a wrapper around the C libsyck library and very fast. There is a view, Catalyst::View::JSON, however it puts the JSON string in the response body because that is what Dojo and other libraries expect. Since AJAX libraries don't idnetify themselves in anyway to the server (e.g. user agent), the Catalyst View would probably need a patch to with a configuration switch to populate X-JSON instead of the response body. For now, I'm using JSON::Syck directly. The following are the minimal calls to use. If you have UTF-8 output, see C::V::JSON for UTF-8 encoding.

$c->res->header(
    'X-JSON' => JSON::Syck::Dump( \%args );
);

I've put together some example code that I thought would be better placed on the wiki. It can be found at: Prototype.js, JSON and Catalyst.

UPDATE: After running into the IE max header length issue, I've decided to put the JSON object in the response body and manually eval request.responseText on the client.

del.icio.us:Prototype, JSON and Catalyst digg:Prototype, JSON and Catalyst reddit:Prototype, JSON and Catalyst spurl:Prototype, JSON and Catalyst wists:Prototype, JSON and Catalyst simpy:Prototype, JSON and Catalyst newsvine:Prototype, JSON and Catalyst blinklist:Prototype, JSON and Catalyst furl:Prototype, JSON and Catalyst fark:Prototype, JSON and Catalyst blogmarks:Prototype, JSON and Catalyst Y!:Prototype, JSON and Catalyst smarking:Prototype, JSON and Catalyst magnolia:Prototype, JSON and Catalyst segnalo:Prototype, JSON and Catalyst

6 comments