0

I'm using the code shown below to save a new record in Ember-Model.

var saveResult = this.get('model').save();  
saveResult.then (function(value) {$('#statusArea').html('Save succedded.\n'),
                 function(value) {$('#statusArea').html('Save failed.\n')});

Everything worked as expected on the server side. I can see the correct 'post' message coming across, and able to save the data to the DB. But no matter what status I return from the server (I've tried 200, 201, and 204), the promise always falls to the failed routine. I have two questions:

1) Am I using the Ember.RSVP.promise returned from Ember-Model correctly in the code shown above?

2) If yes, what do I have to return from the server to reflect success? I have full control on the server side, and can basically return anything necessary.

ptmoy2
  • 311
  • 1
  • 4
  • 13
  • Btw, have you looked at `value` when your function hits the failed route? – Kingpin2k Nov 20 '13 at 02:53
  • Have you considered using jQuery ajax hooks? They seem to be more convenient for your case and are easier to control. http://api.jquery.com/jQuery.ajaxSetup/ – Yury Svechinsky Nov 20 '13 at 09:48
  • Yury, not sure what you mean. Since Ember-model is controlling the ajax calls during a save, is your suggestion that I should scrap Ember-model and roll my own data layer, or hack the Ember-Model code to do what I need? – ptmoy2 Nov 20 '13 at 22:01

1 Answers1

0

yes you are

Create your own rest adapter and override the save method

App.MyRestAdapter = Ember.RESTAdapter.extend({

  saveRecord: function(record) {
    var primaryKey = get(record.constructor, 'primaryKey'),
      url = this.buildURL(record.constructor, get(record, primaryKey)),
      self = this;

  // this is the default implementation, you're blowing up on self.didSaveRecord,
  // you should laugh a little bit noting the todo to implement an api that doesn't
  // return data :)

  //  return this.ajax(url, record.toJSON(), "PUT").then(function(data) {  // TODO: Some APIs may or may not return data
  //    self.didSaveRecord(record, data);
  //    return record;
  //  });

      // technically you could just do
      // return this.ajax(url, record.toJSON(), "PUT");
      // but if you ever want to massage it based on the response in the future, here's the spot
      return this.ajax(url, record.toJSON(), "PUT").then(function(data) {
        return record;
      });

  },
Kingpin2k
  • 47,277
  • 10
  • 78
  • 96
  • So just return status=204, and the original JSON that was received by the server? Is this standard practice or a requirement of Ember and/or Ember-model? Why the unnecessary network traffic? – ptmoy2 Nov 20 '13 at 03:12
  • if you're returning a 204, it wouldn't make since to include the data, a 200 with the data. A usual use case is I created a record, but I have no ID associated with it yet (usually defined by the server) – Kingpin2k Nov 20 '13 at 03:23
  • I've tried returning 204 with no response text, as well as 200 & 201 with response text = "ok". All falls through to the promise error routine. 'value' on my latest run contains the following: Object{readyState=4, responseText="ok", status=201, statusText="Created" then=null, etc etc} – ptmoy2 Nov 20 '13 at 03:24
  • BTW, when I use jquery's $getJSON, if I return just 204, the jquery promise falls to the success routine. In my application, I let the user define the id, which I just validate for uniqueness. So server doesn't really need to return the model; but I will if necessary just to get the RSVP promise to work correctly. – ptmoy2 Nov 20 '13 at 03:29
  • It's not the promise that's breaking, it would be ember data. Additionally using jquery's getJSON you aren't getting an A+ promise, you're getting a deferred promise, you'll want to use Ember.$.getJSON in the future. – Kingpin2k Nov 20 '13 at 03:38
  • My guess is it's trying to serialize those values coming back and it fails, I'm not completely sure why the 204 with no response doesn't work. – Kingpin2k Nov 20 '13 at 03:40
  • I'm actually using Ember-Model, but I think you're right. Ember-Model definitely has its problems. My biggest problem with it now is that the isDirty flag doesn't go to false when a property in a hasMany relationship is changed; this keeps modified data from being sent to the server for persistence. – ptmoy2 Nov 20 '13 at 05:30
  • Oh snap, why didn't you say so, I'm very familiar with EM, I'll update above. – Kingpin2k Nov 20 '13 at 05:39
  • N/m, you did say it was ember model, I think I just don't believe people since everyone says EM when half of the time they are referring to ED. – Kingpin2k Nov 20 '13 at 05:47
  • And one last random comment, I switched from EM to ED because of the fact that EM doesn't seem to be doing much in the realm of going forward etc. Additionally the relationships are a mess in EM. That being said, it works, and is much better than manually managing your records client side. – Kingpin2k Nov 20 '13 at 06:12
  • Kingpin2k, thanks for all your help. I still need to figure a way around the isDirty problem in EM. I wish they would bring back the embedded support in ED. ED was working fairly well for me until this: http://stackoverflow.com/questions/19871825/how-to-get-ember-data-restadapter-to-send-hasmany-records-to-server problem, which forced me to switch over to EM. – ptmoy2 Nov 20 '13 at 07:44
  • Kingpin2, what's the difference between Ember.$.getJSON and the regular jquery $.getJSON? I can't seem to find documentation on Ember.$.getJSON on the Ember site. – ptmoy2 Nov 21 '13 at 22:24
  • Ember wraps it in a RSVP promise instead of a jquery deferred promise. – Kingpin2k Nov 21 '13 at 22:35
  • 1
    It's not mentioned in the Ember API documentation for some reason. So is the usage syntax identical to $.getJSON except for the promise? – ptmoy2 Nov 21 '13 at 22:41