No context when registering transforms

Ember Data
1

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.

1 Like
2

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?

3

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

4

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.

5

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