Add support for extra parameters to Model.save() & RecordArray.save()

[MikeAski]

This is especially useful when having to pass extra context data to the server, along with a standard resource action.

[MikeAski]

The Travis build is failing for some other reason... 😿

[igorT]

I restarted the build, it now seems to fail due to the tests you added.

[MikeAski]

Oops... Indeed, this time it was me: was running in the browser, but not on command-line. Fixed 😅

[tomdale]

@MikeAski: Can you explain what kind of extra context data/metadata you need to include with the save? In general, we try to avoid APIs like this that serve as sidechannels to allow disparate parts of the system to communicate.

[sandstrom]

Perhaps something like an operation, defined on the adapter, could be used to support non-CRUD actions. @MikeAski, would something like this be helpful in your case?

Here is an example from the Stripe API[1]. We've got similar ones in ours.

High-level example of how a solution could work.

// in router
record.operation('refund');

// in adapter
var ChargeAdapter = RESTAdapter.extend({
  operations: {
    'refund' : { path: '/charges/:id/refund', method: 'put' },
  }
})

For things like this we currently do an out-of-band plain xhr, and then use pushPayload on the response, to update the model state. This works, but some form of support within ED would be useful.

Naming is tentative, I'm not sure 'operation' is the ideal word here.

[1] The Strips API has a bunch of these, https://stripe.com/docs/api/curl#refund_charge

[MikeAski]

@tomdale My need is to address a legacy API, which has extra behaviour flags passed along with resource attributes. The exact case is user profile update, which takes two flags indicating if the admin wishes to have the updated user's password randomly generated & another indicating if anyway some notification should be sent to the given user.

@sandstrom In my case, I am needing the extra parameters on CRUD actions. So I think your suggestion is interesting but is another topic 😉

[sandstrom]

@MikeAski Perhaps you can use readonly attributes myFlag: DS.attr('boolean', {serialize: false}) for these two flags. Set like normal properties. Then, in your model-specific serializer, you'd read these of the record and make the necessary adjustments to the payload. Would that work for you?

[MikeAski]

@sandstrom It worked, indeed. I had to override serializeIntoHash and got the same result. Thanks for the tip.