Callbacks for 404, 403, and 500 errors for ajax calls #473

Closed
wants to merge 7 commits into
from

Conversation

Projects
None yet
3 participants
@osis

osis commented Nov 14, 2012

This commit implements callbacks for the usual HTTP error status codes. These callbacks allow you initialize your adapter like so:

App.store = DS.Store.create({
  revision: 7,
  adapter: DS.RESTAdapter.create({ 
    bulkCommit: false,
    errorResponse: function(jqXHR) {
      console.log('Encoutered ' + jqXHR.status + ' error');
      // Set a flag on the current state to prevent multiple renders
      if (!App.router.currentState.get('hasError')) {
        router = App.router;
        // Render Error View
        router.get('applicationController').connectOutlet('error')
        router.currentState.set('hasError', true);
      } 
    }
  })
});

There is a case for an error view to replace the entire layout instead of rendering in ApplicationController's outlet. This implementation should be flexible enough to handle this and variety of other scenarios.

I was also thinking that the callback should just return the status code instead of the jqXHR object but again, I like the flexibility of having all the data from the response.

@wagenet

This comment has been minimized.

Show comment Hide comment
@wagenet

wagenet Nov 15, 2012

Owner

It's hard for me to tell what you're actually doing here since the commits look screwed up. That said, I know we've wanted a comprehensive solution for error handling. My concern is that we really want to make sure we think about things and have a solid proposal in place. Instead of people just adding code, I'd like to see someone put together a proposal that we can discuss. /cc @wycats

Owner

wagenet commented Nov 15, 2012

It's hard for me to tell what you're actually doing here since the commits look screwed up. That said, I know we've wanted a comprehensive solution for error handling. My concern is that we really want to make sure we think about things and have a solid proposal in place. Instead of people just adding code, I'd like to see someone put together a proposal that we can discuss. /cc @wycats

@osis

This comment has been minimized.

Show comment Hide comment
@osis

osis Nov 15, 2012

Sorry about the messy commits. The idea is to have a callback and provide the information needed, from the request, so that people can act upon it.

I don't think that Ember Data should make any assumptions on how error views are implemented, hence the ambiguous callback that gets applied to the adapter:

errorResponse: function(jqXHR) {
      console.log('Encoutered ' + jqXHR.status + ' error');
      // Set a flag on the current state to prevent multiple renders
      if (!App.router.currentState.get('hasError')) {
        router = App.router;
        // Render Error View
        router.get('applicationController').connectOutlet('error')
        router.currentState.set('hasError', true);
      } 
    }

Which gets called every time there is a 403/404/500 error in the adapter via:

 ajax: function(url, type, hash) {
    hash.url = url;
    hash.type = type;
    hash.dataType = 'json';
    hash.contentType = 'application/json; charset=utf-8';
    hash.context = this;

    if (hash.data && type !== 'GET') {
      hash.data = JSON.stringify(hash.data);
    }

    // Add callbacks for error statuses
    if (hash.statusCode === undefined) { hash.statusCode = {}; }
    hash.statusCode['404'] = this.errorResponse;
    hash.statusCode['403'] = this.errorResponse;
    hash.statusCode['500'] = this.errorResponse;

    jQuery.ajax(hash);
  },

  errorResponse: function(jqXHR, textStatus) {
    if (this.responseError !== undefined) this.responseError(jqXHR, textStatus);
  },

osis commented Nov 15, 2012

Sorry about the messy commits. The idea is to have a callback and provide the information needed, from the request, so that people can act upon it.

I don't think that Ember Data should make any assumptions on how error views are implemented, hence the ambiguous callback that gets applied to the adapter:

errorResponse: function(jqXHR) {
      console.log('Encoutered ' + jqXHR.status + ' error');
      // Set a flag on the current state to prevent multiple renders
      if (!App.router.currentState.get('hasError')) {
        router = App.router;
        // Render Error View
        router.get('applicationController').connectOutlet('error')
        router.currentState.set('hasError', true);
      } 
    }

Which gets called every time there is a 403/404/500 error in the adapter via:

 ajax: function(url, type, hash) {
    hash.url = url;
    hash.type = type;
    hash.dataType = 'json';
    hash.contentType = 'application/json; charset=utf-8';
    hash.context = this;

    if (hash.data && type !== 'GET') {
      hash.data = JSON.stringify(hash.data);
    }

    // Add callbacks for error statuses
    if (hash.statusCode === undefined) { hash.statusCode = {}; }
    hash.statusCode['404'] = this.errorResponse;
    hash.statusCode['403'] = this.errorResponse;
    hash.statusCode['500'] = this.errorResponse;

    jQuery.ajax(hash);
  },

  errorResponse: function(jqXHR, textStatus) {
    if (this.responseError !== undefined) this.responseError(jqXHR, textStatus);
  },
@tomdale

This comment has been minimized.

Show comment Hide comment
@tomdale

tomdale Nov 20, 2012

Owner

Thanks for the pull request. We have a ton of ideas about how we want to implement error handling in an exhaustive way. This implementation hardcodes HTTP semantics when we really need to think about errors across a broad spectrum of adapter types—JSON over HTTP, WebSockets, and IndexedDB.

We are about to merge another pull request that adds similarly lightweight error handling in a transport-independent way. Hopefully soon me and @wycats will get some time to really revamp how errors are handled in Ember Data.

Owner

tomdale commented Nov 20, 2012

Thanks for the pull request. We have a ton of ideas about how we want to implement error handling in an exhaustive way. This implementation hardcodes HTTP semantics when we really need to think about errors across a broad spectrum of adapter types—JSON over HTTP, WebSockets, and IndexedDB.

We are about to merge another pull request that adds similarly lightweight error handling in a transport-independent way. Hopefully soon me and @wycats will get some time to really revamp how errors are handled in Ember Data.

@tomdale tomdale closed this Nov 20, 2012

@osis

This comment has been minimized.

Show comment Hide comment
@osis

osis Nov 21, 2012

Cool. Thanks! Can you link to the pull request?

osis commented Nov 21, 2012

Cool. Thanks! Can you link to the pull request?

@tomdale

This comment has been minimized.

Show comment Hide comment
@tomdale

tomdale Nov 28, 2012

Owner
Owner

tomdale commented Nov 28, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment