Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActiveModelAdapter for Polymorphic Types Still Expects camelcase properties from response #1574

Closed
eschan opened this issue Dec 12, 2013 · 11 comments

Comments

@eschan
Copy link

eschan commented Dec 12, 2013

From my testing, it looks like the ActiveModelAdapter still expects camelcasing for polymorphic references.

App.Image = DS.Model.extend({
  imageable: DS.belongsTo('imageable', { polymorphic: true })
})

App.Imageable = DS.Model.extend({
  image: DS.belongsTo('image')
})

App.User = App.Imageable.extend({
  name: DS.attr('string')
})

If my server response looks like this. The imageable property on Image.Imageable is undefined.

images: [{
  id: 1,
  imageable_id: 1,
  imageable_type: 'User'
  url: 'http://test.com/photo.jpg'
}]

But when the server response looks like this. The imageable property on Image.Imageable is populated with a User

images: [{
  id: 1,
  imageable: 1,
  imageableType: 'User'
  url: 'http://test.com/photo.jpg'
}]

I understand that the changes for 1.0.0 beta 3 was to remove the underscore for the RESTAdaptor, but I also thought that underscores where supported for the ActiveModelAdapter.

I am using:
Ember Data : 1.0.0-beta.3

@bradleypriest
Copy link
Member

Hey @eschan can you try with the canary build and see if this is still an issue, there have been a lot of improvements to the ActiveModelAdapter since then

@abuiles
Copy link
Member

abuiles commented Dec 12, 2013

@bradleypriest @eschan are you using AMS on your backend too? I've been using AMS with polymorphic types without problems for the last months, though my response looks different.

For me it looks something like this

 images: [{
   id: 1,
   imageable: {
     id: 1,
     type: 'User'
    },
   url: 'http://test.com/photo.jpg'
 }]

My AMS Serializer looks something like this

  class ImageSerializer < ActiveModel::Serializer
      attributes :id, :url
      embed :ids
      has_one :imageable, polymorphic: true
    end

Also I double check and currently against canary returning imageable_id and imageable_type doesn't work, @bradleypriest is that something that we want to support in AMS too?

@bradleypriest
Copy link
Member

@abuiles we were waiting for the AMS Rails gem to work out what format they were going to send down polymorphic formats in (has_one vs has_many vs belongs_to). Last time I checked it was still in flux

@eschan
Copy link
Author

eschan commented Dec 12, 2013

@bradleypriest just tried it with this configuration and still not working

DEBUG: Ember      : 1.4.0-beta.1+canary.6d93fc6f ember.js?body=1:3289
DEBUG: Ember Data : 1.0.0-beta.4+canary.3464f975 ember.js?body=1:3289
DEBUG: Handlebars : 1.1.1 ember.js?body=1:3289
DEBUG: jQuery     : 1.10.2 ember.js?body=1:3289

Only way to get it to work was to implement an application serializer to handle these types

App.ApplicationSerializer = DS.ActiveModelSerializer.extend({
  extractSingle: function(store, type, payload, id, requestType) {
    if (payload.image) {
      payload.image.imageable     = payload.image.imageable_id;
      payload.image.imageableType = payload.image.imageable_type;
    };

    if (payload.images) {
      payload.images.forEach(function(image) {
        image.imageable     = image.imageable_id;
        image.imageableType = image.imageable_type;
      });
    }

    return this._super(store, type, payload, id, requestType);
  },
  extractArray: function(store, type, payload, id, requestType) {
    payload.images.forEach(function(image) {
      image.imageable     = image.imageable_id;
      image.imageableType = image.imageable_type;
    });

    return this._super(store, type, payload, id, requestType);
  }
});

@bradleypriest
Copy link
Member

Hi @eschan, quick question, are you using the default ActiveModelSerializer gem's polymorphic serialization?

@eschan
Copy link
Author

eschan commented Dec 12, 2013

@bradleypriest yup

Image Model

class Image < ActiveRecord::Base
  belongs_to :imageable, :polymorphic => true
end

Image Serializer

class ApplicationSerializer < ActiveModel::Serializer
  embed :ids, include: true
end

class ImageSerializer < ApplicationSerializer
  attributes :id, :url, :width, :height, :original_filename, :filesize, :image_type, :imageable_id, :imageable_type
end

@bradleypriest
Copy link
Member

Is this the same as #1457 C/D?

@eschan
Copy link
Author

eschan commented Dec 13, 2013

@bradleypriest i don't think this helps with my issue. My polymorphic associations are stored with the naming convention of "imageable_id" and "imageable_type"... while his is only refers to "type".

I thought ember needed [class]_type or [class]Type as the convention.

unless my response from rails is completely wrong. :)

@bradleypriest
Copy link
Member

There was a note at the bottom of that one saying they were still undecided on the format. I haven't been following closely, maybe they decided on a different one

@eschan
Copy link
Author

eschan commented Dec 13, 2013

@bradleypriest it's obviously working with "imageable" and "imageableType", so my currently solution is to continue using a serializer to remap my properties to match the expected results.

My assumption as of now is that the DS.ActiveModelSerializer conventions don't match up when send and receiving data.

When saving my objects to the server it creates

{
  imageable_id: 1 
  imageable_type: "User"
}

but... when receiving objects, its expects

{
  imageable: 1 
  imageableType: "User"
}

so my conclusion is that, either sending is wrong or receiving is wrong... they can't use two different conventions

@bmac
Copy link
Member

bmac commented Mar 18, 2015

Looks like this was fixed by #1662

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants