Комментарии 20
Вот вопрос, который меня мучал изначально, в гайде не смог найти толковый ответ. Все примеры, которые есть по 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'а, такое реализовать?
Спасибо!
/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'а, такое реализовать?
Спасибо!
Ember.js все равно какой ответ придет от сервера — главное что-бы он содержал всю нужную ему информацию именно в том формате к отором ее будет ожидать приложение.
В данном случае вам надо начать копать со стороны клиента и приспособить ответ сервера клиенту. Не зная проблематики вопроса в деталях я бы вам посоветовал создать класс dashboard в котором вам надо будет назначить связи с другими объектами:
Можно реализовать двумя способами. Вызывайте в шаблоне dashboard хелпер render и как модель отдайте ему связь. Или можете создать компонент и отдать ему нужный объект.
Ну и на последок, ответ от сервера долже выглядеть примерно вот так:
В данном случае вам надо начать копать со стороны клиента и приспособить ответ сервера клиенту. Не зная проблематики вопроса в деталях я бы вам посоветовал создать класс 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]
}
}
Я решал эту проблему так. В роутере:
Потом можно в setupController растащить этот объект на модели:
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);
},
Крутое решение с Ember.RSVP.hash, спасибо!
А второй кусок можно сделать чуть изящнее, если назвать свойства dashboard и content:
А второй кусок можно сделать чуть изящнее, если назвать свойства dashboard и content:
setupController: function(controller, models) {
controller.setProperties(models);
}
Спасибо за статью!
Действительно, на первый взгляд все понятно и логично, но как дела заходят дальше документации — приходится ломать голову и перерывать интернет.
Может подскажете достойные ресурсы для понимания Ember, Ember-data?
Действительно, на первый взгляд все понятно и логично, но как дела заходят дальше документации — приходится ломать голову и перерывать интернет.
Может подскажете достойные ресурсы для понимания Ember, Ember-data?
К сожалению, все что есть по Ember-data на данный момент это куски информации разбросанные по офицальным докам.
Из достойных могу вам посоветовать курс Codeschool или мою книгу. Остальные материалы по Ember'у, с которыми я сталкивался, устройство фреймворка и его особенности опичывают только поверхностно.
Из достойных могу вам посоветовать курс Codeschool или мою книгу. Остальные материалы по Ember'у, с которыми я сталкивался, устройство фреймворка и его особенности опичывают только поверхностно.
Есть еще 'Ember.js in action' на manning.com, но насколько она хороша пока не могу сказать. В codeschool лично я разочаровался. Все-таки вставка кусков кода в нужные места не слишком помогает пониманию кухни. Если они ничего не поменяли, конечно.
Как же всё сложно, наверно я слишком туп для ember.
Точно не буду юзать, 4ый год пишу на чистом js, ни о чём не жалею.
Точно не буду юзать, 4ый год пишу на чистом js, ни о чём не жалею.
Хотите сказать, что если я создам PostModel, мне в PostsRoute model не придется переопределять?
Разве модель не должна называться просто Post (без приставки Model)?
Кроме того предложение «Затем Ember.js обработанные данные забирает у контроллера и отдает их шаблону.» не совсем верно. Ember.js не «отбирает» данные у контроллера, а исполняет шаблон (т.к. в это время шаблон уже представляет собой функцию) и в качестве контекста (объект, к чьим свойствам будет обращаться шаблон) использует контроллер.
Далее Вы зачем-то поставили в один ряд partial, render и компоненты. partial и render всего лишь хелперы в шаблонах, которые указывают, как именно нужно вставить шаблон/вид в текущий шаблон. Вы также не упомянули другой важный хелпер — view, который используется намного чаще, чем partial.
Компоненты — это специальные виды, которые сами себе являются контроллером.
И позвольте не согласиться с первым тезисом Вашей статьи. Ember.js просто другой. А сложность — это понятие сугубо субъективное, как мне кажется.
Кроме того предложение «Затем Ember.js обработанные данные забирает у контроллера и отдает их шаблону.» не совсем верно. Ember.js не «отбирает» данные у контроллера, а исполняет шаблон (т.к. в это время шаблон уже представляет собой функцию) и в качестве контекста (объект, к чьим свойствам будет обращаться шаблон) использует контроллер.
Далее Вы зачем-то поставили в один ряд partial, render и компоненты. partial и render всего лишь хелперы в шаблонах, которые указывают, как именно нужно вставить шаблон/вид в текущий шаблон. Вы также не упомянули другой важный хелпер — view, который используется намного чаще, чем partial.
Компоненты — это специальные виды, которые сами себе являются контроллером.
И позвольте не согласиться с первым тезисом Вашей статьи. Ember.js просто другой. А сложность — это понятие сугубо субъективное, как мне кажется.
Присоединюсь к замечаниям. Смущает что на схеме (как я поял) controller имеет один view. Это не так, контроллер понятия не имеет о view, он используется как контекст для view (и для template), таким образом мы можем использовать один экземпляр controller для многих view.
Тем не менее спасибо за статью.
Тем не менее спасибо за статью.
Похоже, что вы работали с Yii Framework, и сразу назвали все своими именами. По сто раз перечитывал статью автора, пока не наткнулся на ваш комментарий. Спасибо за хелперы и компоненты!
Купил я книгу, разбираюсь, могу сказать, что книга устарела немного, если следовать 1 в 1 тому, как там написано, встречаются не совсем понятные ошибки, которые не так просто понять и исправить, и почти все касаются ember-data. Я бы посоветовал исправить начальные главы книги, чтобы так сказать, не разочаровывать читателей ). В целом книга неплоха.
А у нас кстати вакансия есть на ember в Москве, интересно кому?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анатомия Ember.js (часть первая, теоретическая)