No context when registering transforms


In trying to get information about the attribute that’s being transformed in my registerTransform function. Mainly I need the name of the attribute.

My use case is for creating a metaObject which would have a value and meta property. The value would be the unchanged value, and the meta will be populated from a key/value hash based on the attribute. The objects toString would return the value.

It would be used like this:

    {{username}} {{! "Bob"}}
    {{username.meta}} {{! "User Name"}}

Another use case could be for transforming keys to values, so if the data you get from the server are keys/ids that have a corresponding value, it would be necessary to know the attribute type, since keys could overlap across different attributes.

    DS.RESTAdapter.registerTransform("keyValueObject", { 
      serialize: function (value) {
        return value.get("key");
      deserialize: function (key) {
        var keyValues = {
          3: "768 kbps - 1.5 mbps",
          4: "1.5 - 3 mbps",
          5: "3 - 6 mbps",
          default: "Not Specified"

        // Missing a way to know what type of attribute this is..
        // would have an object: attributeMap = { attributeType: {...}, ... };

        return Ember.Object.create({
          value: keyValues[key] || keyValues.default,
          key: key,
          toString: function () {
            return this.value;

The problem is that there is no such parameter, nor does this hold any context.

The work around, would be to create a separate transform for each attribute, with it’s own key/value pairs.


I’m having exactly this problem and it would be very useful to be able to get the attribute name when registering transforms. Is there anything new about this?


Nothing that I know of, yet. I created an issue, maybe it’ll get some attention.


oops… accidentally hit delete.

Although more context for the transforms isn’t a bad idea. Typically for these sorts of “humanized” transforms I use either a handlebars helper or computed property to decorate for human consumption. Leaving the adapter level transforms strictly for data transport.


That is a good point, thanks for sharing your view @stefan. I’ll close the issue.