Разъедините контроллер и просмотрите в ExtJs - PullRequest
2 голосов
/ 12 марта 2012

Я изучаю ExtJ и пытаюсь найти лучший способ организовать мой будущий проект. Я начал с учебника по ExtJs MVC http://docs.sencha.com/ext-js/4-0/#!/guide/application_architecture

В этой архитектуре есть что-то, что мне не нравится: Контроллер «знает» о виджетах представлений и таким образом добавляет прослушиватели событий

this.control({
            'viewport > userlist':{
                itemdblclick:this.editUser
            },
            'useredit button[action=save]':{
                click:this.updateUser
            }
        });

Мы начинаем большой проект с 500+ формами. Я верю, что в таких крупных проектах такой подход создаст большой беспорядок. Есть ли способ развязать контроллер и посмотреть?

Например, в GWT они используют шаблон MVP, где Presenter не знает о внутренностях представления и взаимодействует с представлением через интерфейс «Дисплей». Я знаю, что у Javascript нет интерфейсов, но может быть есть какой-то способ эмулировать их в Extjs.

Я бы хотел, чтобы мой контроллер был примерно таким:

editButton = viewInterface.getEditButton();
editButton.on('click', function(btn, e, eOpts) {
    eventBus.fireEvent(editUserEvent);
});

Возможно ли это?

Ответы [ 3 ]

4 голосов
/ 12 марта 2012

Абсолютно возможно. Создайте метод getEditButton в вашем представлении и возвращайте все, что вы хотите. Это не проблема.

Мой 2с однако для развязки вида и контроллера. Я также в настоящее время работаю над довольно большим проектом. Возможно, он не такой большой, как у вас, но у нас будет около 100+ видов / контроллеров.

Я пытаюсь создать этот проект, используя два основных правила:

  1. Если у меня есть какая-то общая логика, будь то в поле зрения или в контроллере - я создаю базовый класс и перемещаю эту логику туда. Итак, позже - я просто расширил его, чтобы дочерние представления / контроллеры получили ту же функциональность.

  2. Я оставляю код, который не связан с бизнес-логикой приложений, внутри классов представления - например, если у меня есть сетка и мне нужно добавить специальный код для выбора всех записей в сетке или для отображения количества записей и количество выбранных записей в сетке внутри строки состояния - этот код идет на просмотр класса. Таким образом, контроллер не имеет представления об этих «простых» задачах и фокусируется только на бизнес-логике приложения.

1 голос
/ 03 января 2013

Я бы предпочел, чтобы представления генерировали значимые события, такие как 'edit', используя fireEvent.

Контроллер будет знать о представлении и может отслеживать событие «редактирования» в представлении.

Вид:

this.on(this.btnEdit, 'click', function(){ this.fireEvent('edit');},this);

Контроллер:

this.mon(this.viewInstance, 'edit', this.doEdit, this);

Таким образом, контроллер дозы не знает о представлениях внутренних органов.

1 голос
/ 03 апреля 2012

Наличие логики в представлении действительно отрицательно сказывается на цели паттерна MVP.Я рекомендую проверить deftjs , так как это делает запросы компонентов более чистыми.Поскольку большинство действий пользователя выполняется с помощью элементов управления, например кнопки, я даю им действие и ищу это уникальное действие, например, вход в систему.

 control: {
    submitButton: {
        selector: 'button[action=login]',
        listeners: {'click': 'login'}
    }
 }

Проблема с вышесказанным заключается в том, что он все еще привязывает контроллер к компоненту представления, кнопке, поскольку он ссылается на его тип.Вы можете заменить это на id, но я тоже не фанат этого.Я считаю, что лучший способ получить эту функциональность - это сделать так, чтобы у deftjs была более общая модель событий, которую они, вероятно, имеют в дорожной карте, поскольку они основывают ее на таких проектах, как RobotLegs.Если никто не предоставит эту функцию в ближайшее время, я, вероятно, попробую.

И последнее, но не менее важное, если вам нужно добавить логику в компонент, вероятно, лучше всего расширить этот компонент и протестировать его отдельно от вашего.просмотры.

...