Разве модель не должна называться просто Post (без приставки Model)?
Кроме того предложение «Затем Ember.js обработанные данные забирает у контроллера и отдает их шаблону.» не совсем верно. Ember.js не «отбирает» данные у контроллера, а исполняет шаблон (т.к. в это время шаблон уже представляет собой функцию) и в качестве контекста (объект, к чьим свойствам будет обращаться шаблон) использует контроллер.
Далее Вы зачем-то поставили в один ряд partial, render и компоненты. partial и render всего лишь хелперы в шаблонах, которые указывают, как именно нужно вставить шаблон/вид в текущий шаблон. Вы также не упомянули другой важный хелпер — view, который используется намного чаще, чем partial.
Компоненты — это специальные виды, которые сами себе являются контроллером.
И позвольте не согласиться с первым тезисом Вашей статьи. Ember.js просто другой. А сложность — это понятие сугубо субъективное, как мне кажется.
Вот лишь несколько доводов в пользу неиспользования нами Ext.Direct:
1. Использование Ext.Direct приводит к тому, что серверные функции (вернее, их имена) «видны» на клиенте
2. API нужно только для связывания, но не для переноса логики с сервера на клиент. Поэтому, на наш взгляд, подход Ext.Direct несколько странен
3. В нашей команде над серверной частью и фронтендом работают разные люди. Нет необходимости знать, какая функция на сервере обеспечивает нужный функционал. Есть документация к API и сборщик API-библиотечки на клиенте (по мотивам аналогичной от Marelle). Структура API задается JSON-ом.
Мне это дало функционал аля Хром — набираешь → Enter → результаты поиска в Гугле.
А убрать searchbar можно и без стилей — Customize… на тулбаре и выкидываешь поле.
Да, действительно. Удалил указанное расширение и все заработало. Спасибо.
В качестве замены Omnibar изменил значение настройки keyword.URL в about:config.
Кроме того предложение «Затем Ember.js обработанные данные забирает у контроллера и отдает их шаблону.» не совсем верно. Ember.js не «отбирает» данные у контроллера, а исполняет шаблон (т.к. в это время шаблон уже представляет собой функцию) и в качестве контекста (объект, к чьим свойствам будет обращаться шаблон) использует контроллер.
Далее Вы зачем-то поставили в один ряд partial, render и компоненты. partial и render всего лишь хелперы в шаблонах, которые указывают, как именно нужно вставить шаблон/вид в текущий шаблон. Вы также не упомянули другой важный хелпер — view, который используется намного чаще, чем partial.
Компоненты — это специальные виды, которые сами себе являются контроллером.
И позвольте не согласиться с первым тезисом Вашей статьи. Ember.js просто другой. А сложность — это понятие сугубо субъективное, как мне кажется.
1. Использование Ext.Direct приводит к тому, что серверные функции (вернее, их имена) «видны» на клиенте
2. API нужно только для связывания, но не для переноса логики с сервера на клиент. Поэтому, на наш взгляд, подход Ext.Direct несколько странен
3. В нашей команде над серверной частью и фронтендом работают разные люди. Нет необходимости знать, какая функция на сервере обеспечивает нужный функционал. Есть документация к API и сборщик API-библиотечки на клиенте (по мотивам аналогичной от Marelle). Структура API задается JSON-ом.
А убрать searchbar можно и без стилей — Customize… на тулбаре и выкидываешь поле.
В качестве замены Omnibar изменил значение настройки keyword.URL в about:config.
А вот что у меня получилось после небольших манипуляций с userChrome.css — http://habreffect.ru/2c5/23db44708/Firefox4.png