Through long-available browser quirks/features, javascript has been available for requests across disparate domains.  But, other resources, such as text files (eg, handlebars templates) have had more restrictions placed on them.  Recently, CORS support has enhanced the ability to make these requests.  Here's how you get your text files from another domain via requirejs.



## CORS
[CORS](https://developer.mozilla.org/en/http_access_control) is a great feature for modern browsers that allows a site on a domain A to request a resource from domain B without restriction, because domain B already said that it's willing to accept those requests. In an [article on CORS by Remy Sharp](http://remysharp.com/2011/04/21/getting-cors-working/), he outlines in more detail how to setup your server to be CORS ready.  Simply, it comes down to the server responding with an http header.  To allow all sites to request a server's resources:

```http
Access-Control-Allow-Origin: *
```

To allow a whitelist of sites to request resources, the server must give the same header with only certain sites listed:

```http
Access-Control-Allow-Origin: http://rockycode.com http://builtbyjake.com
```

What servers can [support CORS](http://html5please.com/#cors)?  Firefox and Chrome have supported it for some time.  IE8 has its own Microsoft flavor.  iOS and Android also have strong support for a few version back.  Check out the [detailed stats on caniuse.com](http://caniuse.com/cors).

## RequireJs

[RequireJs](http://requirejs.org/) Is a fantastic Javascript loader that allows for client-side async loading of js and other static assets.  For textual, non-code things, there is a [`text` plugin](http://requirejs.org/docs/download.html#text).  

Because RequireJs knows about non-CORS-enabled browser restrictions, by default it functions differently for cross-domain requests.  In the current (2.0.0) implementation of the text plugin, line 163, the plugin decides whether to do a normal XHR (more lenient on text assets) request or to skip to the `else` statement to require what it will [assume is javascript](https://groups.google.com/group/requirejs/browse_thread/thread/bc0608ef5f8943e7/3a1cafaa93869c32) because that's requestable across domains:

```js
//Load the text. Use XHR if possible and in a browser.
if (!hasLocation || useXhr(url, defaultProtocol, defaultHostName, defaultPort)) {
  text.get(url, function (content) {
    text.finishLoad(name, parsed.strip, content, onLoad);
  }, function (err) {
    if (onLoad.error) {
        onLoad.error(err);
    }
  });
} else {
  //Need to fetch the resource across domains. Assume
  //the resource has been optimized into a JS module. Fetch
  //by the module name + extension, but do not include the
  //!strip part to avoid file system issues.
  req([nonStripName], function (content) {
    text.finishLoad(parsed.moduleName + '.' + parsed.ext,
                    parsed.strip, content, onLoad);
  });
}
```

To allow CORS-enabled servers to get resources requested from them, we [configure RequireJs](http://requirejs.org/docs/api.html#config) to override the `getXhr` function to return true:

(Note: 25 Oct 2012 - Syntax updated per Chris' comment below)

```js
require.config({
  config: {
    text: {
      useXhr: function (url, protocol, hostname, port) {
        // allow cross-domain requests
        // remote server allows CORS
        return true;
      }
    }
  }
});
```

Now you should be able to ask for various and sundry things across domains and continue enjoy the RequireJs goodness -- now multiplied:

```js
require('text!http://anotherDomain/my.html', function (my) {
  // have fun!
});
```

Through long-available browser quirks/features, javascript has been available for requests across disparate domains.  But, other resources, such as text fil

Cross-Domain RequireJs Text

Don't you hate developing a blasted simple webpage that does some asynchronous requests that gets you into cross-origin policy trouble.  If you just read a `.html` file off the file system, this will bite you.  But, it's easy to get around.  Just host your .html file on a simple http server.  And it's easy to make that happen.  Here's one way.



## Attacked by Snakes

First, Verify you have python installed:

```bash
> python --version
Python 2.7.3
```

##'Tis a Gift to Be Simple

Then navigate to the directory that you'd like to serve up and type:

```bash
python -m SimpleHTTPServer 5000
```

Where "5000" is the port you'd like to serve it on.  (Defaults to 80.)  Then point your browser to:

    http://localhost:5000

And rock your local dev.

Don't you hate developing a blasted simple webpage that does some asynchronous requests that gets you into cross-origin policy trouble.  If you just read a

Serve a Directory

BackboneJS is setup to do some pretty sweet single-page app action.  And of course, a single page app will probably be wanting to talk to web services on the server.  And if your server code is doing the Java jive, then a great way to expose your REST services is via JAX-RS.  It's as easy as Mikey singin' ABC-123!



Note:  These examples use AMD-style modules in Javascript.  I personally use [RequireJS](http://requirejs.org/) for my module loading fettish.

[BackboneJS](http://documentcloud.github.com/backbone/) Model Url
--------------------

To tell a client-side [`Backbone.Model`](http://documentcloud.github.com/backbone/#Model) object where it syncs to on the server, it needs a [`url`](http://documentcloud.github.com/backbone/#Model-url) field like so (in `Cat.js`):

```javascript
define(function () {
  return Backbone.Model.extend({
    url: '/ws/cat'
  });
});
```

The `url` field can be a string literal or a function that has more meat to it.  The point is that it be awesome and point correctly to your REST endpoint exposed on the server.

If you want to fetch a model from the server, you can call [`fetch()`](http://documentcloud.github.com/backbone/#Model-fetch) directly on the model a la `myModelInstance.fetch()`, but in practice you won't know which specific model you want initially, and instead your model will be part of a [collection](http://documentcloud.github.com/backbone/#Collection-fetch).  But let's say that your model had an id of, say, 1334, and you wanted to get it off the server, you'd call `fetch()` and that call will delegate to [`Backbone.sync`](http://documentcloud.github.com/backbone/#Sync), making an HTTP GET to:

```bash
GET /ws/cat/1334
```

When you save a model by calling `myModelInstance.save()`, it delegates to `Backbone.sync` in the same way.  If it's a new object (in Backbone, that means it doesn't yet have an `id` field) that was initially created on the client and thus doesn't appear on the server yet, it'll make an HTTP POST to:

```bash
POST /ws/cat
```

If it's already an object that was requested from the server (and has, say, and id of 1334) and is now being updated based on client action, it'll make an HTTP PUT to:

```bash
PUT /ws/cat/1334
```

(BTW, HTTP DELETE works the same way as PUT.)

JAX-RS Endpoints
----------------

[JAX-RS](http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services) endpoints are exceedingly easy to setup.  It's all annotation-based, so you're free to rejoice.  Here's an example (It's also a [Spring `@Controller`](http://static.springsource.org/spring/docs/2.5.x/reference/beans.html)): 

```java

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Controller;

@Controller
@Scope("singleton")
@Path("/ws/cat")
public class CatRest {

  @GET
  @Produces("application/json")
  public List<CatDto> getCats() {
    return getCatsFromSomewhere();
  }

  @POST
  @Produces("application/json")
  @Consumes("application/json")
  public CatDto createCat(CatDto dto) {
    return saveCatAndReturnInstanceWithId();      
  }

  @PUT
  @Path("/{id}")
  @Produces("application/json")
  public CatDto updateCat(CatDto dto) {
    return updateCatReturnSameInstance();
  }

  @DELETE
  @Path("/{id}")
  @Produces("application/json")
  public void deleteCat(@PathParam("id") Long id) {
    removeTheBlastedCat();
  }

}
```

This should all be fairly self-descriptive.  It matches the HTTP actions that can be made from Backbone.sync.  So what is JAX-RS doing for you.  It's allowing your methods to be exposed as rest endpoints by the simple addition of the `@GET`, `@POST`, etc annotations.  

Note that the `@Path` matches the `url` field on your Backbone model.  And `@PUT` and `@DELETE` append an `{id}` variable to the end of the path.  In the case of `@PUT`, the id gets set on the `CatDto`.  For HTTP DELETE, a body is not send, just the HTTP request, so a `@PathParam` is all you get.  

If these operations are successful, they all [respond with](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) HTTP 200, except for DELETE which returns 204 NO CONTENT.

JAX-RS is also dealing with the marshalling and unmarshalling from, in this case, json into and out of `CatDto`.  The `CatDto`, but like most [DTOs](http://en.wikipedia.org/wiki/Data_Transfer_Object) just provides a wrapper around your actually domain object that exposes only what you desire in your web service (ie, possibly not everything in domain objects).

And what does the DTO look like?  I'm glad you asked.

DTOs -- The Backbone / JAX-RS Gophers
-------------------------------------

Here's `CatDto.java`:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;

@SuppressWarnings("serial")
@XmlRootElement
public class CatDto implements Serializable {

  private Long id;

  private String name;

  // getters and setters...

}
```

There's not much to it  -- just like a DTO should be.

By default, when JAX-RS gets some JSON in the body of an HTTP request, it's going to try and bind fields in the JSON to the DTO fields.  So, a nice piece of JSON from the client that could be unmarshalled into a `CatDto` instance would look something like:

```javascript
{
  id: 1334,
  name: 'Cotton-headed Ninnymuggins'
}
```

It's as magical as [maple syrup](http://www.youtube.com/watch?v=Fig956-MuVA)!

Binding form fields to a Backbone Model
---------------------------------------

By default, BackboneJS has no built-in ability to automatically bind the values that are entered in form fields in the UI to fields in the corresponding `Backbone.Model` object.  But, Derick Bailey has created a nice little Backbone plugin for this purpose called [Backbone.ModelBinding](https://github.com/derickbailey/backbone.modelbinding).  This is a [KnockoutJS](http://knockoutjs.com/)-inspired dom to model (and vice versa) data transfer lib.

If you don't have `Backbone.ModelBinding` on your project, you'll have to do your own setting of fields when you save with the "set and save" idiom from Backbone that will look something like:

```javascript
myModel.save({
  name: $("#name-form-field").val()
});
```

If you do want to use `Backbone.ModelBinding`, make sure you make it globally available (as a dependency [ordered](http://requirejs.org/docs/api.html#order) after Backbone itself) just put this snippet in your `Backbone.View` code:
  
```javascript
define(function () {
  return Backbone.View.extend({
    initialize: function () {
      // ...
      Backbone.ModelBinding.bind(this);
    },
    // more view goodness
  }
});
```

You should also be aware of some of the limitations of `Backbone.ModelBinding`.  For instance, it can only bind anything that a Backbone.Model can get() and set(), which doesn't include nested objects or arrays.  So, some stuff you'll have to set manually anyway if you have objects more interesting than cats.  

Also note that any inputs on the form, that are sometimes fields you don't care about or necessarily want attached to your `Backbone.Model`, show up there anyway.  So now when you call `myModelInstance.save()`, the json that gets sent to the server will be laden with extra coconuts, potentially like this:


```javascript
{
  id: 1334,
  name: 'Mittens',
  ladenWith: 'coconuts,
  africaan: true
}
```

And just between you and me, that won't work with our currently-defined `CatDto`.  It's time for a season reboot:

Backbone.ModelBinding and JAX-RS
--------------------------------

If we get these extra, albeit more exciting, fields in the json, when unmarshalling happens, we get a late Christmas present:

```text
[12/26/12 00:00:0:001] 0000000e Wr WebApplicationExceptionMapper: WebApplicationException has been caught :
Unrecognized field "laden_with" (Class CatDto), not marked as ignorable 
  at [Source: org.apache.cxf.transport.http.AbstractHTTPDestination$1@b98117; line: 1, column: 286] (through reference chain: CatDto["laden_with"])
```

"Not marked as ignorable", eh?  A couple ways to fix this.  The one requiring more typing and creating a brittle dto first.  Back to `CatDto.java`:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;

@SuppressWarnings("serial")
@XmlRootElement
public class CatDto implements Serializable {

  private Long id;

  private String name;

  @XmlTransient
  private String ladeWith;

  @XmlTransient
  private Boolean africaan;

  // getters and setters...

}
```

We can label each of the undesirable fields with `@XmlTransient`, but oh the pain.

It's maybe not all that bad that this blows big chunks.  Perhaps more secure.  You want to validate input at the REST endpoints.  Maybe this is the way you personally do it.  I do it elsewhere -- in the converstion from DTOs to domain objects and with Hibernate validators on those objects.

So, for me the better option that allows me to not have to go back and mess with `CatDto.java` as much is:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;
import org.codehaus.jackson.annotate.JsonIgnoreProperties;

@SuppressWarnings("serial")
@XmlRootElement
@JsonIgnoreProperties(ignoreUnknown = true)
public class CatDto implements Serializable {

  private Long id;

  private String name;

  // getters and setters...

}
```

This is whitelisting instead of blacklisting.  Lots less maintenance when more fields show up as unrecognizable.  Either way, I just use what I want on the server, so just ignore *everything* else with the [`@JsonIgnoreProperties`](http://wiki.fasterxml.com/JacksonAnnotations) annotation.

Lots of HTTP
------------

This kind of programming is really quite fun.  And it feels pretty clean.  There's lots of cool UI possibilities for single-page apps on the client.  BackboneJS and RequireJS makes handling the complexity there much more doable.  And data-handling REST endpoints on the backend are super simple.  The simplicity of the REST endpoints makes Java feel a little heavy-handed on ceremony (like it often seems these days), but JAX-RS is a great framework if Java is what you have on the backend.

BackboneJS is setup to do some pretty sweet single-page app action.  And of course, a single page app will probably be wanting to talk to web services on th

Backbone and JAX-RS

Jquery, Ajax, Json, Django -- this is quite a laundry list of technologies.  In fact, it's pretty much the whole stack: client tech, server requests, over-the-network data format, and a backend app server.  In the following slidedeck and example code, we're going to touch on the whole stack and not get too deep into any one area.  By the end, you should be able to at least have a grasp of what technologies one can use in an Ajax Django application, a little bit of what they're capable of, and then, hopefully, a list in your brain that you can go back, reference, and then drill into specific technologies when you want to go build something similar yourself.



Here's the breakdown of the [slideshare slidedeck](http://www.slideshare.net/rockycode/jquery-ajax-json-on-django):

Jquery
---------

- A Javascript framework
- "Write less, do more"
- Select the dom - $(".selection")
- Traverse the dom - $(".my").parent()
- Manipulate the dom - $(".my").append("dectomy")
- Provides an Ajax API - $.ajax()
- Framework for providing your own functionality (plugins) - $(".new").operate()

Ajax
---------

- Asynchronous Javascript and Xml
- Jquery API - $.ajax(), $.get(), $.post(), $.getJSON()

Json
---------

- JavaScript Object Notation
- Terse
- Flexible, nestable
- Native in Javascript

Django
---------

- Web framework built on Python
- "encourages... clean, pragmatic design"
- Django-piston - mini-framework to create RESTful APIs for your data


Because this presentation was originally written for a Django-loving audience who wanted to know more about Jquery, Ajax, and Json, I decided to make the most basic Django app that could easily function with the other (mostly) client-based technologies.  

Sample App
--------------

The result was the "ask" app ([source here](https://bitbucket.org/jtsnake/ask>)).  In the app, we have what is basically an FAQ.  Previously on the Internetz somewhere, I saw a fun FAQ where two people answered every question and almost the most fun thing for me was comparing the answers of the two people to one another.  The difference in their answers was often humorous and entertaining in addition to answering the question.  The questions were also often ridiculous.  This seemed like a fun format, so I asked my friend, [Steve](http://rockycode.com/blog/author/steveo/) to answer a few questions with me, and we created the app.  Techs:

- [Jquery](http://jquery.com/)
- [Jquery Templates](http://api.jquery.com/category/plugins/templates/)
- [Sammy.js](http://code.quirkey.com/sammy/)
- [django-piston](https://bitbucket.org/jespern/django-piston/wiki/Home)
- [Django](http://www.djangoproject.com/)

On the backend, django-piston allows us to easily define handlers for the data that we want to expose through a RESTful API.  We define the urls to get to the handlers at, and boom!, we have json-flavored data being queried by Django, and displayed to requesters at the defined urls.

From here, we're very client heavy.  

Jquery Templates
--------------------

Jquery gives us an easy api to $.get() the data that we want.  We use Jquery Templates to do what Django templates may normally do for us:  Apply markup to our dynamic data.  With Jquery Templates, the server can send almost-raw data and the client, which seems to be a naturally fitting place for presentation transformation anyway, can now be fully in charge of what markup data should be displayed within.

Sammy.js
------------

We also used just a portion of Sammy.js, the routing feature, to take care of the controller logic.  I like the Sammy.js routing for the same reason that I like the Django urls.py routing: it's very imperative, which I feel is elegant:  "Here's my url pattern, and here's the logic that goes with that."

Why SOUIT
-------------

[SOUIT](http://souit.org/) = Service-oriented User Interface Technology.  Why would we want to create an app like this?  Doesn't Django have the ability to do this all for me -- url routing, templating?  It does.  But that doesn't mean that it wouldn't be more fitting to have this happen elsewhere, if only partially.  Since browsers are becoming beefier and more capable of handling client side transformations like templating and with tools like Jquery and Sammy that make request and response routing very clean, why not try it there?  Throw in the requirement of "asynchronous"ity, and you may just be happy you have the ability to do all this on the client.  And it's cool -- worth an additional 5 points.  Plus, now that our web client is essentially a single-page app with all the smarts it needs to function, we can consider different backend technologies too.  Hmmm, a database that exposes its data through mere REST APIs?  CouchDb, maybe?

What do you think?  This example 'ask' application is definitely not extremely compelling, but what are the best uses of this particular client-heavy technology stack that you can think of?

Jquery, Ajax, Json, Django -- this is quite a laundry list of technologies.  In fact, it's pretty much the whole stack.

Jquery, Ajax, Json on Django

Jquery gives a great, easy-to-use mechanism for extending its API and creating your own plugins.  For stuff that looks like it could be useful generally, you should really try to put it into a nice little plugin package.  For submit buttons, there is a general thought that they shouldn't be clicked twice (especially for functions such as financial transactions), so I created a plugin that fits an app that I have been working on recently, where there are many, many submit buttons, saving very granual pieces of content through ajax requests.



The "safesubmit" plugin is going to disable submit buttons when clicked and, in most cases, re-enable them when the ajax request has completed.  On your app, if you had a class called "safe" on all the submit buttons that you wanted to exhibit this behavior, you could enable the plugin functionality with one line:

```javascript 
$(".safe").safesubmit();
```

And that's it.  It's simple and powerful.  It's likely, however, because this happened on my project as well that the client code is going to have more complicated business rules.  In our case, someone added extra form validation where the length of the submitted field was checked -- if it passed, it was submitted; otherwise, it was not.  In that case, the plugin never re-enabled the button to be again pressable.  So, I exposed the functions of the plugin to be public, allowing you to shortcircuit the normal flow, essentially notifying the plugin to the submit failure.  For example, here's a submit's onclick event snippet:

```javascript
if (valid()) {
  $.ajax ({ ... });
} else {
  $.fn.safesubmit.failsubmit($(this));
}
```

If you need, the "safe" and "unsafe" methods are also made public.  You can call them whenever needed.  "safe" is the state of having the click disabled.  "unsafe" means you can click the button. 

You can also change default settings.  For instance, by default when you put the button in "safe" mode, it adds disabled="disabled" attribute to the button and adds a class of "disabled".  You have the option of changing all 3 opts.  For instance, maybe you have a different class:

```css
.dead {
  background-color: #ababab;
}
```

and want to apply that class instead.  Try this:

```javascript
$.fn.safesubmit.defaults.disabled_class = "dead";
$(".safe").safesubmit();
```

Download the script on [Github](https://github.com/jtsnake/jquery-safesubmit).

Jquery gives a great, easy-to-use mechanism for extending its API and creating your own plugins.  For stuff that looks like it could be useful generally, yo

Jquery Plugin: safesubmit

Have you ever had a problem with ajax requests caching in Internet Explorer.  I have, and recently I came across a nicer solution than I have traditionally used.  In the past, I have used a unique parameter on the url to keep IE from caching previous requests to the same url, like so:



```javascript
$.ajax({
  ...
  url: "/r/e/s/t/?unique=" + new Date().getTime()
});
```

But, wouldn't it be nice to keep your urls clean and not have to add this chunk of code for every Ajax call.  On a recent project, we have a url rewriter through which all requests are routed.  I added a call to this function (in xquery), to tell the browser not to cache any response.

Xquery
------

```
declare function no-cache() {
  let $is-ajax := xdmp:get-request-header("X-Requested-With") eq "XMLHttpRequest"
  return if ($is-ajax) then
    let $expire-immediately := xdmp:add-response-header("Expires", "-1")
    let $no-cache := xdmp:add-response-header("Cache-Control", "no-cache, no-store")
    return ()
  else ()
};
```

For Java, there's something similar:

Java
----
```java
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.ResponseBuilder;

public class CacheUtil {
  public static Response BuildNoCache(ResponseBuilder builder) {
    return builder.header("Expires", "-1").header("Cache-Control", "no-cache, no-store").build();
  }
}
```

How do you control your ajax caching problems in the pseudo-browsr of IE?

Have you ever had a problem with ajax requests caching in Internet Explorer.  I have, and recently I came across a nicer solution than I have traditionally