Почему аргументы create () не ведут себя больше как setProperties ()?

Что-то, что я нахожу очень нелогичным в Ember, это то, что вы можете перезаписать вычисляемые функции установщика свойств (http://emberjs.com/#toc_computed-properties-setters с аргументамиcreate(), Увидетьhttp://jsfiddle.net/zJQJw/2/

Я нашел лучший обходной путь для этого, чтобы позвонитьcreate().setProperties(properties) вместоcreate(properties), но это кажется ненужным для меня. Я понимаю, что это может сломать некоторые приложения на данный момент, но вы бы могли сделатьcreate() вести себя больше какsetProperties()?

Моя мотивация спрашивать этоinit() будет вызван раньшеsetProperties() при использованииcreate().setProperties(properties) шаблон. Это еще не было большой проблемой, но я вижу, что это нежелательно в некоторых ситуациях. Это полностью надуманный пример, но, может быть, вы видите, к чему я клоню?http://jsfiddle.net/QJ8vX/2/

Единственная причина, по которой я могу видеть текущее поведение, заключается в том, чтобы делать переопределенные для метода установки методы. Но в этих случаях вы могли бы так же легко сделатьMyClass.extend({ overridenMethod: ... }).create(properties)

Будет ли такое изменение рассматриваться для Ember 1.0? Или у меня просто неверное представление о том, как должна работать объектная модель Ember?

 Adam Murray02 мая 2012 г., 23:33
Я подалаgithub.com/emberjs/ember.js/issues/777так что не стесняйтесь звонить вон там.
 Lance Pollard11 мая 2012 г., 07:27
некоторые из нас здесь также обсуждали это с командой ember, и они в основном сказали, что не меняют ее. Я с тобой согласен.
 Christopher Swasey02 мая 2012 г., 22:02
Я поднял эту точную проблему на канале, в основном академически, и ответ был (перефразируя) «Я не вижу, как мы меняем поведение create». Однако я бы посоветовал вам открыть дискуссионную тему на github.
 Adam Murray16 мая 2012 г., 04:30
Кто-то спросил, почему я хотел использовать вычисляемые функции установщика свойств, и одна из причин состояла в том, чтобы обеспечить, что двунаправленные отношения всегда действительны. Теперь я прибег к созданию собственного метода .setFoo (value) вместо того, чтобы использовать шаблон с более естественным ощущением .set ('foo & apos ;, value). Мне не нравится несоответствие, потому что оно сбивает с толку людей, которые не пишут код, но должны его использовать. Но это работает. Это просто кажется одной из тех особенностей, на которые люди будут жаловаться вечно ... о, хорошо.

Ответы на вопрос(2)

Решение Вопроса

по которой мы отодвинули это изменение, состоит в том, что он делает невозможным переопределение свойств, определенных в базовых классах, в качестве вычисляемых свойств. Например, вEmber.View,template свойство является вычисляемым свойством:

template: Ember.computed(function(key, value) {
  if (value !== undefined) { return value; }

  var templateName = get(this, 'templateName'),
      template = this.templateForName(templateName, 'template');

  return template || get(this, 'defaultTemplate');
}).property('templateName').cacheable(),

При создании подклассаEmber.ViewВы можете переопределить это определение с помощью явной функции шаблона:

Ember.View.create({ template: Ember.Handlebars.compile('...') });

Если вычисляемое свойство не обрабатывает случай установщика, эта попытка переопределить вычисленное свойство будет молчаливой ошибкой.

Если мы внесли это изменение, оно также вводит другие вопросы о том, должны ли наблюдатели запускать свойства, передаваемые вcreate метод. И то, и другое возможно реализовать, и существуют веские аргументы для обоих подходов.

В преддверии 1.0 кажется разумным рассмотреть подход, который бы:

change create to use setProperties semantics add a new API (override or createWithOverride) that would retain the existing semantics, in case you explicitly wanted to override existing computed properties suppress observers for properties set due to create (or decide not to) find a way to detect and warn about attempts to use the create API with computed properties that do not implement setters.

Мне нужно было бы обсудить это подробнее и рассмотреть последствия для существующих приложений, но это, безусловно, кое-что, что стоит рассмотреть, так как это определенно большой вопрос для новых разработчиков. Тот факт, что нам нужно было изменить поведение дляember-data довольно хорошая подсказка, что что-то не так.

 11 мая 2016 г., 17:04
Это касается только до 1.0.create() был изменен на использованиеsetProperties() here, Новый API, который использует старую семантикуcreateWithMixins().
 18 июл. 2012 г., 08:56
Я хотел бы знать, если это такая же проблема, какstackoverflow.com/questions/11412550/…
 Adam Murray25 июл. 2012 г., 17:43
Спасибо за подробный ответ, Иегуда. Мне интересно посмотреть, как это может быть решено в будущей версии. Пули, которые вы перечислили, звучат многообещающе.

Em.Object.reopenClass({ 
   create: function(config) {
       return this._super().setProperties(config); 
   }
});
 26 февр. 2013 г., 15:32
Хм, это мой вид взлома. Реализация.

Ваш ответ на вопрос