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

json iconcatalyst icondojo icon

JSON XSS exploit: don't use text/html

Posted in , , , , , Tue, 25 Jul 2006 01:40:00 GMT

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

del.icio.us:JSON XSS exploit: don't use text/html digg:JSON XSS exploit: don't use text/html reddit:JSON XSS exploit: don't use text/html spurl:JSON XSS exploit: don't use text/html wists:JSON XSS exploit: don't use text/html simpy:JSON XSS exploit: don't use text/html newsvine:JSON XSS exploit: don't use text/html blinklist:JSON XSS exploit: don't use text/html furl:JSON XSS exploit: don't use text/html fark:JSON XSS exploit: don't use text/html blogmarks:JSON XSS exploit: don't use text/html Y!:JSON XSS exploit: don't use text/html smarking:JSON XSS exploit: don't use text/html magnolia:JSON XSS exploit: don't use text/html segnalo:JSON XSS exploit: don't use text/html

2 comments

yui iconjquery icondojo icongoogle iconscriptaculous icon

Autocomplete Survey

Posted in , , , , , , Tue, 18 Jul 2006 04:15:00 GMT

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.

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.

del.icio.us:Autocomplete Survey digg:Autocomplete Survey reddit:Autocomplete Survey spurl:Autocomplete Survey wists:Autocomplete Survey simpy:Autocomplete Survey newsvine:Autocomplete Survey blinklist:Autocomplete Survey furl:Autocomplete Survey fark:Autocomplete Survey blogmarks:Autocomplete Survey Y!:Autocomplete Survey smarking:Autocomplete Survey magnolia:Autocomplete Survey segnalo:Autocomplete Survey

6 comments

dojo icon

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

Posted in , Fri, 14 Jul 2006 04:57:00 GMT

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.

del.icio.us:Dojo - dojo.addOnLoad vs. body onload and window.onload digg:Dojo - dojo.addOnLoad vs. body onload and window.onload reddit:Dojo - dojo.addOnLoad vs. body onload and window.onload spurl:Dojo - dojo.addOnLoad vs. body onload and window.onload wists:Dojo - dojo.addOnLoad vs. body onload and window.onload simpy:Dojo - dojo.addOnLoad vs. body onload and window.onload newsvine:Dojo - dojo.addOnLoad vs. body onload and window.onload blinklist:Dojo - dojo.addOnLoad vs. body onload and window.onload furl:Dojo - dojo.addOnLoad vs. body onload and window.onload fark:Dojo - dojo.addOnLoad vs. body onload and window.onload blogmarks:Dojo - dojo.addOnLoad vs. body onload and window.onload Y!:Dojo - dojo.addOnLoad vs. body onload and window.onload smarking:Dojo - dojo.addOnLoad vs. body onload and window.onload magnolia:Dojo - dojo.addOnLoad vs. body onload and window.onload segnalo:Dojo - dojo.addOnLoad vs. body onload and window.onload

3 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 icon

Dojo - Setting the ComboBox Default Value

Posted in , , Wed, 14 Jun 2006 08:39:00 GMT

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.

del.icio.us:Dojo - Setting the ComboBox Default Value digg:Dojo - Setting the ComboBox Default Value reddit:Dojo - Setting the ComboBox Default Value spurl:Dojo - Setting the ComboBox Default Value wists:Dojo - Setting the ComboBox Default Value simpy:Dojo - Setting the ComboBox Default Value newsvine:Dojo - Setting the ComboBox Default Value blinklist:Dojo - Setting the ComboBox Default Value furl:Dojo - Setting the ComboBox Default Value fark:Dojo - Setting the ComboBox Default Value blogmarks:Dojo - Setting the ComboBox Default Value Y!:Dojo - Setting the ComboBox Default Value smarking:Dojo - Setting the ComboBox Default Value magnolia:Dojo - Setting the ComboBox Default Value segnalo:Dojo - Setting the ComboBox Default Value

3 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

dojo iconscriptaculous icon

Dojo's ComboBox Not Ready for Prime Time?

Posted in , , , Sun, 04 Jun 2006 06:21:00 GMT

I've been happily developing with Prototype and Scriptaculous for a while now but was recently convinced to look at Dojo. To start, I was pretty happy with dojo.io.bind but disappointed that I wasn't able to get the Dojo scripts to load from a remote server. Having gotten dojo.io.bind to work, I was off to test my first widget, Dojo's ComboBox, which offers functionality similar to the Scriptaculous autocomplete widget. I've been using Dojo 0.3.0. The Dojo ComboBox Nightly Test is often mentioned as a good place to start so I went there first. Eventually I also spent some time reading and implementing the code at Java.net's AJAX with Dojo and JSON page. In the end I came away disappointed due to several bugs and strange behaviors listed below:

  1. Default value: Dojo does not let you set a default value via the HTML or any other way. To get a default value to show up, I've heard you can write it in with JavaScript but I'm not sure where or when yet due to the DOM onLoad transform issue described below.
  2. Single option bug: when the a resulting list only has one item, hitting the 'enter' key will not close the list. With autocomplete, the single entry will already be populated in the box but not selectable with 'enter'. You need to select the single option in the list with the down key and then hit the 'enter' key. To try this out, type in 'am' for American Samoa in the first input on the nightly test and click 'enter' to continue. I haven't found out whether this is being worked on or not.
  3. DOM onLoad transform: Unlike other libraries, after the page has been rendered Dojo will go back and transform the DOM, replacing dojoTypes with HTML templates. This can cause some timing problems when one wants to use DOM to modify the resulting HTML templates. Dojo provides a dojo.addOnLoad capability to specify a callback function however the new DOM elements don't seem to be available yet. Perhaps something to the effect of dojo.afterDojoOnLoad is needed? This issue can be seen when trying to remove the ComboBox downArrowNode. The ComboBox comes with a down arrow graphic by default and is assigned dojoattachpoint="downArrowNode". With some lists, the reply possibilities are enormous and a default list isn't desirable. When nothing has been typed, it may also give the impression that the list provided is a complete list like a standard select element. I haven't found a good way to disable this yet. Setting the display property on the downArrowNode isn't a good solution because it only works after the page has been rendered. It can't be set immediately rendering the ComboBox input tag because Dojo hasn't been run yet. Setting the display property in the dojo.addOnLoad callback is also too early, i.e. the widget doesn't exist yet. Here's the JS I've been working with:
    var ac = dojo.widget.byId("ac");
    ac.downArrowNode.style.display="none";
    I've also tried setting downArrow and downArrowNode attributes to 0, -1 and false. So far, the only solution I found that works is to delete or comment out the downArrowNode HTML in the following file:
    dojo/src/widget/templates/HtmlComboBox.html
    Not exactly a great solution. Is there a better way to remove the arrow?
  4. Client-side result filtering: It seems like the Dojo javascript does it's own filtering. You give it a list in the format of an Array of Arrays where each inner array has two elements. Dojo then applies it's own filtering. This is nice if you are working off a local list such as a JS file in the Nightly Test example but if you are retrieving a list from a server, the server should have filtered the list already so there's no reason to filter it a second time. This may be partially at fault for the choppy rendering. Is there any way to disable this?
  5. Aribitrary location match: Because Dojo does client-side result filtering, the user isn't guaranteed to see what your server delivers. One area this shows up is that it's not clear how to match any part of the string instead of just the beginning. On the nightly test page, the only results presented are ones where the input matches the start of the string so if someone types a last name and the strings have the format "$first_name $last_name" there would not be a match. The DocTool on dojo.org will match inside the string but the rendering seems choppy and I can't seem to locate it any more. I haven't gotten around to seeing how the DocTool does it. The SVN copy of the doctool.html file shows the following which does not result in the desired non-start match for me:
    <input
        dojoType="combobox"
        id="search"
        autoComplete="false"
        value=""
        style="width: 300px;"
    >
  6. HTML result rendering: Often it's nice to show the user which part of the string matched, especially if the match is not at the beginning of the string. This is done by bolding the matching letters a la Gmail. If HTML is included in the array, it is rendered literally instead of interpreted as HTML. Because Dojo does client-side filtering, HTML mark up will also cause matching to fail. With Scriptaculous, you can add HTML mark-up to the results and it will render properly. Perhaps with Dojo, the HTML needs to be added by client-side JavaScript?

These are my initial observations of Dojo's ComboBox. It seems very difficult to get it to DWIW and very different than the Scriptaculous Autocomplete which just works and has been working. Scriptaculous autocomplete has been working like champ for me since prototype 1.3.1 and it's now on 1.5.0 rc0. Please let me know of any ways to accomplish the above Dojo ComboBox issues. Also let me know if you're using Dojo's ComboBox in production and / or your experiences with it.

del.icio.us:Dojo's ComboBox Not Ready for Prime Time? digg:Dojo's ComboBox Not Ready for Prime Time? reddit:Dojo's ComboBox Not Ready for Prime Time? spurl:Dojo's ComboBox Not Ready for Prime Time? wists:Dojo's ComboBox Not Ready for Prime Time? simpy:Dojo's ComboBox Not Ready for Prime Time? newsvine:Dojo's ComboBox Not Ready for Prime Time? blinklist:Dojo's ComboBox Not Ready for Prime Time? furl:Dojo's ComboBox Not Ready for Prime Time? fark:Dojo's ComboBox Not Ready for Prime Time? blogmarks:Dojo's ComboBox Not Ready for Prime Time? Y!:Dojo's ComboBox Not Ready for Prime Time? smarking:Dojo's ComboBox Not Ready for Prime Time? magnolia:Dojo's ComboBox Not Ready for Prime Time? segnalo:Dojo's ComboBox Not Ready for Prime Time?

4 comments

json icondojo icon

Dojo - Using dojo.io.bind

Posted in , , Sun, 04 Jun 2006 04:15:00 GMT

I recently looked into Dojo Toolkit 0.3.0's dojo.io.bind to perform AJAX requests because of it's good handling of memory leaks. I checked out the dojotoolkit.org intro page which was okay but didn't cover how to pass parameters or how to process a JSON response so I thought I'd put some info together here. Here are a few things worth knowing:

  1. A dojo response has a type that is typically set to load or error, though sometimes it may be neither. With dojo, type=="load" means success.
  2. Dojo.io.bind has a few handlers to process the response. The load handler is executed when the response type=="load" and the error handler is executed when the response type=="error". There is also a catch-all handle handler that can accept all response types so you can process a response that has a type that's neither load nor error.
  3. If request parameters are set as a hashref using content, dojo.io.bind will automatically turn them into form post parameters
  4. The response mimetype (or content-type) is set in the client JavaScript. Dojo uses this to determine how to process the response. Dojo ignores content-types set by the server

Here are two examples to help put the above together. The examples cover a plain HTML fragment response as well as a JSON response. Both examples submit a hashref. Dojo can also submit an entire form automatically. This is covered on the Dojo.IO Intro link above and isn't covered here, for now. Thanks to Toby Corkindale who posted his saveHandler function to the catalyst mailing list.

Example 1: HTML processed by load
This first example retrieves a single fragment of HTML in the response body and processes it using the load handler.

dojo.io.bind({
    url: "/binduri",
    method: "post",
    /* optional content. If the content is in the
     * form of a hashref they are converted to
     * post paramters */
    content: {
        username: "George",
        password: "curious"
    },
    load: function(type,data,evt) {
        if (data) alert('Response Data: '+data);
    },
    mimetype:'text/html'
});

Example 2: JSON processed by handle
This second example processes a JSON response using the all-in-one handle handler. The handle is typically used in special situations where load and error are not appropriate such as a progress bar. It is shown here just to provide the syntax. To process a JSON response, set the dojo.io.bind mimetype to text/json and return the JSON object in the response body.

dojo.io.bind({
    url: "/binduri",
    method: "post",
    /* optional content. If the content is in the
     * form of a hashref they are converted to
     * post paramters */
    content: {
        username: "George",
        password: "curious"
    },
    handle: function(type,data,evt) {
        if (type=='load') {
            alert( 'Successful response' );
            if (data.myItem)
                alert('Response JSON Item: '
                +data.myItem);
        } else if (type=='error') {
            alert('A error has occurred');
        } else {
            alert('Some other event has occurred');
        }
    },
    mimetype:'text/json'
});

Conclusion
Dojo.io has a nice interface that has a few conveniences including auto-conversion of a hashref to request form parameters and auto-eval of JSON set in the response body. Along with the good memory leak handling for IE, a very nice implementation.

del.icio.us:Dojo - Using dojo.io.bind digg:Dojo - Using dojo.io.bind reddit:Dojo - Using dojo.io.bind spurl:Dojo - Using dojo.io.bind wists:Dojo - Using dojo.io.bind simpy:Dojo - Using dojo.io.bind newsvine:Dojo - Using dojo.io.bind blinklist:Dojo - Using dojo.io.bind furl:Dojo - Using dojo.io.bind fark:Dojo - Using dojo.io.bind blogmarks:Dojo - Using dojo.io.bind Y!:Dojo - Using dojo.io.bind smarking:Dojo - Using dojo.io.bind magnolia:Dojo - Using dojo.io.bind segnalo:Dojo - Using dojo.io.bind

7 comments

dojo icon

Dojo - Remote Script Problem

Posted in , Sun, 04 Jun 2006 04:11:00 GMT

Dojo Toolkit 0.3.0 seems to have a problem loading it's javascript libraries remotely, i.e. when the Dojo scripts are hosted on a server different than where the HTML is. For example, if the page http://www.mysite.com/index.html includes http://www.mystatic.com/dojo/dojo.js. The main Dojo file, dojo.js, runs fine when loaded remotely, however the following fatal errors occur when it attempts to load its external libraries:

FATAL: Could not load 'dojo.io';
   last tried '__package__.js'
FATAL: Could not load 'dojo.widget.ComboBox';
   last tried '__package__.js'

It was suggested this could be due to XSS protections. Scriptaculous' scriptaculous.js, however, has a way around this since it can be loaded remotely and access it's external files (builder.js, controls.js, etc.). Often it's nice to have static files hosted on a separate server. Is there a way to fix this issue for Dojo?

UPDATE 1: For now, I'm going to stick with dojo.io.bind and Scriptaculous autocomplete. A nice thing about this set up is I can load a remote dojo.js browserio build w/o issues since it doesn't need call any external libraries for just bind.

UPDATE 2: Alex Russell provided a uri for cross domain package loading. You can turn on cross domain support by using a custom build and setting the dojoLoader option to xdomain option:

ant -Dprofile=ajax -DdojoLoader=xdomain
  -Ddocless=true clean release intern-strings

If you don't want to build it yourself, James Burke has done it and made it available as dojo-0.3.1-ajax-xd.tar.gz. This page has some more info.

del.icio.us:Dojo - Remote Script Problem digg:Dojo - Remote Script Problem reddit:Dojo - Remote Script Problem spurl:Dojo - Remote Script Problem wists:Dojo - Remote Script Problem simpy:Dojo - Remote Script Problem newsvine:Dojo - Remote Script Problem blinklist:Dojo - Remote Script Problem furl:Dojo - Remote Script Problem fark:Dojo - Remote Script Problem blogmarks:Dojo - Remote Script Problem Y!:Dojo - Remote Script Problem smarking:Dojo - Remote Script Problem magnolia:Dojo - Remote Script Problem segnalo:Dojo - Remote Script Problem

4 comments