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

[unet900]

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

[nekto_O]

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

[Allan Stark]

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

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

[DjDiablo]

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

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

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

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

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

[DjDiablo]

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

пример 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.

[Masat0]

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

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

[DjDiablo]

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

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

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

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

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

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

[Allan Stark]

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

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

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 грида ?

[Allan Stark]

Разобрался.

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

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

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

[DjDiablo]

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

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