Контроллеры в EXT 4
 

Объясните плз какую именно логику нужно ложить в контроллеры в EXT 4 а что ложить во View ??

unet900,
В идеале все методы, кроме initComponent, должны храниться в контроллере, во view только представление (в частности лэйаутинг компонентов). Почитайте -> http://docs.sencha.com/ext-js/4-1/#!...n_architecture

Да... Только если скачать ихний же Sencha Architect 2 (он триальный) и попробовать сваять там приложение MVC, то например логику обработки событий кнопок оно само ложит в view...

Создалось впечатление, что в самой Сенча начали понимать, что с MVC несколько перемудрили...
Да и вот: http://javascript.ru/forum/showthrea...005#post183005

Что касается архитектуры extjs вообще.
Чуть ли не все классы(model/view/controller/component и тд) в extJs, реализует модель поведения observer.
грубо говоря паттерн observer отслеживает события в классах и реагирует на них, а также может сам генерировать события.

View тоже наследует модель поведения от observer, а значит мы можем работать с событиями в view. Но если событий в view стало слишком много, или нам нужно работать с несколькими view, то мы можем создать контроллёр(опять же наследующий observer) которому мы дадим задачу следить за интерисующими нас классами, и заставим контролёр обрабатывать события.

Вдумайтесь.
-Когда мы встаиваем компонент в view, и обрабатываем события компонентов в view, то по сути view в этом случае функционирует как обсервер следящий за событиями в компонентах. Если вложенность больше, то это не что другое как обсервер , следящий за событиями другого observer'а.

-Когда мы создаём контролёр по сути это тот же обсервер следящий за событиями, но в отличии от копонент и view, контролёр нечего неотображает на экране. Думаю при желании один контролёр можно даже научить следить за событиями другого контролёра.

Если угодно то в ExtJs контролёр можно воспринимать как вспомогательную надстройку/следилку за событиями, которую можно использовать по желанию/необходимости. ОДнако необязательность контролёра не означает что он не нужен совсем.

Продемонстрирую несколько подходов

пример 1. Толстый VIEW, он же Быдлокод.
задача. надо нажать на три кнопки, тогда запустится какаянибудь сложная логика.

реализация:
1) в view есть обработчик событий, увеличивающий счётчик при нажатии каждой кнопки.
2) когда значение счётчика достигает 3х, view запускает функцию с требуемой логикой .
3) Исполняется функции с логикой, код функции полностью расположен в view.

получаем огромный уродливый view.

пример 2. Не чистый MVC, реализация слабой связанности паттерном Observer(Наблюдатель).
задача. надо нажать на три кнопки, тогда запустится какаянибудь сложная логика.

реализация:
1) в view есть обработчик событий, увеличивающий счётчик при нажатии каждой кнопки.
2) когда значение счётчика достигает 3х, view генерирует события FIRERUN.
3) подписанный на событие FIRERUN контролёр, видит сообытие и выполняет логику.

вроде всё красиво, хоть идеология MVC не соблюдена в полной мере.

пример 3. чистый MVC с толстым контролёром
Здесь строго настроuо запрещено реагировать на любые события в View, можно только в контролёре.
реализация:
В этом случае реакция на события кнопки происходит в контролёре, когда счётчик достигает 3х запускается метод расположенный в этом же контроллёре.

Иметь толстенький контролёр порой тоже нужно, но чаще не красиво, особенно когда речь идёт об обработке данных.

пример 4. чистый MVC с тонким контролёром
реализация:
всё как в третим примере, однако "сложная логика " (предположим что это обработка данных), размещена не в контролёре а в store или model. А может даже распределена между store и model.

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

В зависимости от принадлежности пользователя к определенной группе необходимо показывать различные наборы кнопок на тулбаре. Откуда должно идти обращение к БД на сервере, чтобы получить группу или список доступных компонент и где эти компоненты должны создаваться? в контроллере или в вьюпорте?

я боюсь что вопрос "как должно быть" не уместен, есть только удобно для вас и неудобно.

Если тулбар более менее сложный то его есть смысл выделить в отдельный компонент.

тогда будет две вероятности , либо подключать разные тулбары в зависимости от группы, либо тулбар должен сам заполнить себя кнопками в зависимости от группы (к примеру будут подключены различные наборы items в initComponents вашего тулбара)

нажатие на кнопки обычно обычно стоит слушать в контролёре.

данные для инициализации приложения можно комфортно получить в application это тоже контролёр, но он контролирует всё приложение.

можно пойти дальше и подключать в application тот viewport который содержит только нужные пользователю компоненты.

Кстати, так и не разобрался, как скажем в контроллере, контролирующем некоторый вью с гридом и кнопками достучаться в обработчике событий к событию нажатия например кнопки?

Например в контроллере:

Ext.define('App.controller.controller_invoices', {
	extend: 'Ext.app.Controller',
	views: ['view_invoices_list'],
	init: function() {
        this.control({
            'view_invoices_list': {
                itemclick: function(view, record, item, index, e, obj) {
                   // тут обрабатываем клик в гриде 
               }
        });
    }
});

Тут все понятно, контроллер следит за ивентами конкретно в гриде (того, который во вью alias:'view_invoices_list').
А как в init: function() зарегистрировать обработчик клика других интерактивных элементов вью, помимо грида, например произвольной кнопки в панели dockedItems грида ?

Разобрался.

Вот это будет работать:

init: function() {
   'view_invoices_list': {
      // тут обрабатываем события в гриде view_invoices_list
   },
   'view_certs_preview_area #print_button': {
      // а тут обрабатываем события в кнопке в панели dockedItems 
   }
}

[off]Честно говоря, начала эта ExtJS меня уже разочаровывать. Вроде и документации навалом, а многие вещи приходится добывать черте-где, в примерах на сторонних сайтах в 10-й странице гуглопоиска, да еще в документации одно и то же разными подходами описывается, попробуй догадайся, какой из них правильный...[/off]

Аналогично, элемент разочарования присутствует.

На самом деле, на extjs многие вещи реализуются сложнее чем без него.