Анатомия Ember.js (часть первая, теоретическая)

[@RuslanZavackiy]

Вот вопрос, который меня мучал изначально, в гайде не смог найти толковый ответ. Все примеры, которые есть по ember'у, очень прямолинейны и далеки от более реальных приложений, как должно выглядеть следующая структура:

/dashboard

этот route содержит в себе несколько компонентов страницы, есть левое меню, которое приходит с сервера, есть данные статистики, есть dashboard статистика, и есть один график. Все это приходит от сервера в одном запросе, разделенными приблизительно так:

{
dashboard: {
data: [{… data1… }, {… data2… }, {… data3… }]
menu: [{… item1… }, {… item2… }, {… item3… }],
indicators: [{… indicator1… }, {… indicator2… }, {… indicator3… }],
statistics: [{… statistics1… }, {… statistics2… }, {… statistics3… }],
}
}

data, menu, indicators, statistics (collection'ы) — разные блоки, темплейты. data1, data2, data3 etc. — это все моделию

и вопрос такой, как в идеологии ember'а, такое реализовать?

Спасибо!

[@iiShrimp]

Ember.js все равно какой ответ придет от сервера — главное что-бы он содержал всю нужную ему информацию именно в том формате к отором ее будет ожидать приложение.

В данном случае вам надо начать копать со стороны клиента и приспособить ответ сервера клиенту. Не зная проблематики вопроса в деталях я бы вам посоветовал создать класс dashboard в котором вам надо будет назначить связи с другими объектами:

App.Dashboard = DS.Store.extend({
  data: DS.hasMany('data'),
  menu: DS.hasMany('menu'),
  indicators: DS.hasMany('indicators'),
  statistics: DS.hasMany('statistics)
});

Можно реализовать двумя способами. Вызывайте в шаблоне dashboard хелпер render и как модель отдайте ему связь. Или можете создать компонент и отдать ему нужный объект.

Ну и на последок, ответ от сервера долже выглядеть примерно вот так:

{
  data: {
    data1: {...},
    data2: {...}
  },

  dashboard: {
    ....
    data: [data.id1, data2.id]
  }
}

[@gagoman]

Я решал эту проблему так. В роутере:

model: function() {
    return Ember.RSVP.hash({
        // use Ember.Data or whatever you whant
       data1: this.store.find('data', /* find query */),
       data2: Ember.$.getJSON(url).then(function(data) {
             return data.summary;
       })
    });
}

Потом можно в setupController растащить этот объект на модели:

     setupController: function(controller, models) {
  var dashboard = models.data1,
      summary = models.data2;

  controller.set('dashboard', dashboard);
  controller.set('content', summary);
},

[@javascript]

Крутое решение с Ember.RSVP.hash, спасибо!

А второй кусок можно сделать чуть изящнее, если назвать свойства dashboard и content:

setupController: function(controller, models) {
  controller.setProperties(models);
}

[@gagoman]

я вначале написал кусок с router. А потом решил дополнить пример, но 3 минут не хватило, поэтому видите, что видите.

[@Fantyk]

Спасибо за статью!
Действительно, на первый взгляд все понятно и логично, но как дела заходят дальше документации — приходится ломать голову и перерывать интернет.
Может подскажете достойные ресурсы для понимания Ember, Ember-data?

[@iiShrimp]

К сожалению, все что есть по Ember-data на данный момент это куски информации разбросанные по офицальным докам.

Из достойных могу вам посоветовать курс Codeschool или мою книгу. Остальные материалы по Ember'у, с которыми я сталкивался, устройство фреймворка и его особенности опичывают только поверхностно.

[@galk_in]

Codeschool платный. Обидно, когда начинаешь заниматься и тут плати. Надо об этом сразу предупреждать.

[@NeXTs_od]

Ну вы словно не из снг, ей богу

[@yul]

Есть еще 'Ember.js in action' на manning.com, но насколько она хороша пока не могу сказать. В codeschool лично я разочаровался. Все-таки вставка кусков кода в нужные места не слишком помогает пониманию кухни. Если они ничего не поменяли, конечно.

[@kidar2]

Как же всё сложно, наверно я слишком туп для ember.
Точно не буду юзать, 4ый год пишу на чистом js, ни о чём не жалею.

[@karudo]

Хотите сказать, что если я создам PostModel, мне в PostsRoute model не придется переопределять?

[@iiShrimp]

Да. Если вы будете придерживаться дефолтных настроек Ember'а то он вам сам в PostsRoute вызовет все доступные модели Post.

[@kwinch]

Разве модель не должна называться просто Post (без приставки Model)?

Кроме того предложение «Затем Ember.js обработанные данные забирает у контроллера и отдает их шаблону.» не совсем верно. Ember.js не «отбирает» данные у контроллера, а исполняет шаблон (т.к. в это время шаблон уже представляет собой функцию) и в качестве контекста (объект, к чьим свойствам будет обращаться шаблон) использует контроллер.

Далее Вы зачем-то поставили в один ряд partial, render и компоненты. partial и render всего лишь хелперы в шаблонах, которые указывают, как именно нужно вставить шаблон/вид в текущий шаблон. Вы также не упомянули другой важный хелпер — view, который используется намного чаще, чем partial.
Компоненты — это специальные виды, которые сами себе являются контроллером.

И позвольте не согласиться с первым тезисом Вашей статьи. Ember.js просто другой. А сложность — это понятие сугубо субъективное, как мне кажется.

[@H1D]

Присоединюсь к замечаниям. Смущает что на схеме (как я поял) controller имеет один view. Это не так, контроллер понятия не имеет о view, он используется как контекст для view (и для template), таким образом мы можем использовать один экземпляр controller для многих view.

Тем не менее спасибо за статью.

[@zakon]

Похоже, что вы работали с Yii Framework, и сразу назвали все своими именами. По сто раз перечитывал статью автора, пока не наткнулся на ваш комментарий. Спасибо за хелперы и компоненты!

[@RuslanZavackiy]

Купил я книгу, разбираюсь, могу сказать, что книга устарела немного, если следовать 1 в 1 тому, как там написано, встречаются не совсем понятные ошибки, которые не так просто понять и исправить, и почти все касаются ember-data. Я бы посоветовал исправить начальные главы книги, чтобы так сказать, не разочаровывать читателей ). В целом книга неплоха.

[@kronos]

А у нас кстати вакансия есть на ember в Москве, интересно кому?

[@H1D]

а у нас в питере есть вакансия =)

[@zakon]

Чем обусловлена приверженность этому фреймворку в вашей компании? Интересно, как исторически сложилось?