Плотно сижу на Quake Live, переодически играю час-потора в день :) С одной стороны потеря времени, но с другой благодаря QL немного прокачал front-end скиллы. 2 года назад имея смутное представление в разработке приложений наклепал вот такую штуку — visualhud.pk69.com/. В этом году было вдохновение, полностью переколбасил на Backbone, вторая версия не только имеет более адекватный код, но и выглядит круче — namad.github.com/visualHUD/. Пока работал над апгрейдом, научился многим интересным веща. В целом, это очень неплохой левел ап для дизайнера :)
Если такая подгрузка является типичной (те разные контроллеры могут потребовать эти действия, а отличатся будут только параметрами), то есть смысл создать отдельный хелпер (библиотеку, да как угодно) и делать вызовы из контроллера
Более сложный пример может быть связан с получением целого набора данных. Например, пользователь перешёл в некий раздел, для работы в котором нам необходимо получить данные для модели, с которой будет работать пользователь, потом загрузить пару дополнительных словарей. Я бы всю эту логику держал бы в контролере. Рендерим блок, показываем индикатор загрузки (можно заблокировать работу оверлеем), делаем серию запросов и по результатам передаём данные внутрь view и начинам работу. Таким образом вью не разруливает загрузку, а только получает на вход сеты данных. Это значит, что мы можем использовать компонент где угодно и сколько угодно раз, просто создавая его и передавая сеты данных, которые ему нужны для работы.
Например, в том же ToDo роль контролера выполнял главный view, он слушал события и принимал решения. При наличии контролера, так делать не обязательно, пусть контролер думает. Минус один жирный вью, остальные могут быть более атомарными, ещё в плюсах простой контролер.
Вообще, моё решение не навязывает какой-то определённый подход. Я всего лишь добавил недостающую сущность, которая позволит разгрузить View от избыточной логики, которую можно переложить на контролеры.
За бизнес-логику в контроллерах надо бить по рукам.
Пожалуй соглашусь.
Вам никогда не приходилось выносить часть интерфейска как одтельное модельное окно? или использовать готовый кусок интерфейса в другом интерфейсе?
Приходилось и всегда без особых проблем.
У вас же есть контроллер который за всеми следит, и если вам нужно будет часть интерфейса в другом месте, вы будете дублировать этот код в другом контроллере.
У меня контролер слушает и направляет. Его цель — обеспечить функционал более высокого уровня, нежели у вью. Вью пусть работает с моделью, обновляется и тд. Как только результат этой работы становится критичным для остального приложения — оповещаем контролер и он уже решает что делать дальше. Примерно такая была идея.
Логика должна быть в моделях. Или это не MVC.
Модель — это данные, там должна быть логинка по модификации этих данных, а роль конроллера — бизнес-логика и связи
Из гибкого backbone вы сделали фреймворк для монолитных, тяжело изменяющихся приложений.
Обоснуете?
Потому что, событие не так просто отследить, если добавлять его в лоб через Backbone.Event.on
Для того, чтобы понять, какой хендлер вызвать, нужно знать
1. Какой контроллер подписан
2. Какой вью генерирует событие
3. Какой именно хендлер нужно вызвать
Поэтому пул событий достаточно сложный, простой подписки через Backbone.Event.on оказалось недостаточно
2) завуалированно и в особо извращённой форме хранит глобальные объекты, доступные в единственном экземпляре
тут определённые сложности, да )
3) создаёт объекты через строковые литералы для геттеров из пункта 2. и ещё, как я понимаю, чтобы передать параметры в конструктор, придётся создавалку переопределять.
на данном этапе там хранятся ссылки только на конструкторы, передача параметров происходит в момент создания сущностей.
Но зачем загружать файлы в произвольном порядке, если есть над этим контроль? Имхо этот вовсе не проблема.
чтобы не парится лишний раз о порядке подключения скриптов, я хочу добавлять компоненты по мере создания приложения, не думая о том, что где-то некорректный порядок
а зачем в контроллере объявлены views: {}, models: {}, collections: {},
для того, чтобы при объявлении контроллера не приходилось лезть в application. таким образом добавление модели или коллекции будет осуществляться в том месте, где это действительно нужно, без лишних телодвижений.
Честно говоря, мне немного подвывихнул мозг способ хранения/получения моделей и коллекций между контроллерами и приложением. Нет ли путей для упрощения подобный схемы?
Не совсем понял, в чём сложность? Модели и коллекции хранятся и создаются приложением. Контроллер просто вызывает функцию-делегат и всё. Или я что-то не понял? :)
В моём случае, я использовал backbone исключительно в определённых целях (см. visualHUD в примерах). Использовать роутер в качестве контроллера я не решился. Зато я решил развлечься и написать простенький application/controller. Результатом я остался доволен, пережитым опытом делюсь на хабре. Такие дела )
Речь как бы о том, что вам нужно хотя бы минимальное вмешательство дизайнера.
Data.Helper.loadData(itemId, callback)Пожалуй соглашусь.
Вам никогда не приходилось выносить часть интерфейска как одтельное модельное окно? или использовать готовый кусок интерфейса в другом интерфейсе?
Приходилось и всегда без особых проблем.
У вас же есть контроллер который за всеми следит, и если вам нужно будет часть интерфейса в другом месте, вы будете дублировать этот код в другом контроллере.
У меня контролер слушает и направляет. Его цель — обеспечить функционал более высокого уровня, нежели у вью. Вью пусть работает с моделью, обновляется и тд. Как только результат этой работы становится критичным для остального приложения — оповещаем контролер и он уже решает что делать дальше. Примерно такая была идея.
Модель — это данные, там должна быть логинка по модификации этих данных, а роль конроллера — бизнес-логика и связи
Из гибкого backbone вы сделали фреймворк для монолитных, тяжело изменяющихся приложений.
Обоснуете?
Backbone.Event.onДля того, чтобы понять, какой хендлер вызвать, нужно знать
1. Какой контроллер подписан
2. Какой вью генерирует событие
3. Какой именно хендлер нужно вызвать
Поэтому пул событий достаточно сложный, простой подписки через
Backbone.Event.onоказалось недостаточнотут определённые сложности, да )
3) создаёт объекты через строковые литералы для геттеров из пункта 2. и ещё, как я понимаю, чтобы передать параметры в конструктор, придётся создавалку переопределять.
на данном этапе там хранятся ссылки только на конструкторы, передача параметров происходит в момент создания сущностей.
Но зачем загружать файлы в произвольном порядке, если есть над этим контроль? Имхо этот вовсе не проблема.
чтобы не парится лишний раз о порядке подключения скриптов, я хочу добавлять компоненты по мере создания приложения, не думая о том, что где-то некорректный порядок
а так да, велосипед-велосипедом.
views: {}, models: {}, collections: {},для того, чтобы при объявлении контроллера не приходилось лезть в application. таким образом добавление модели или коллекции будет осуществляться в том месте, где это действительно нужно, без лишних телодвижений.
Не совсем понял, в чём сложность? Модели и коллекции хранятся и создаются приложением. Контроллер просто вызывает функцию-делегат и всё. Или я что-то не понял? :)