Comments 36
Спасибо за труд конечно, но при такой реализации к сожалению бекбон себя никак не проявляет, слишком простая задача для него.
То есть если мы ставим задачу как вы, вот так локально бекбоне не нужен, его задача организовать приложение. Такой кусочек выглядит конечно красиво и в реализации прост, но когда стоит реальная задача сделать пусть небольшое но все же реальное приложение с парой форм, списков постраничной навигацией, посути все знакомо и просто, но всплывает достаточно много косячков которые надо фиксить.
На хабре много статей, но вних все красиво )) ибо показывают простое для понимания ночиков.
По вашему примеру хочется заметить что хорошо бы эти окошки как-то хранить в списке (тем более вы андерскор конечно же подключили) чтобы каждый раз не шерстить дом в поисках окна, ну и если уж делать то уходить от ненужного прописывания стилей. все помаксимому в css стили в js коде делаеют его менее читаемым это я про position, width, height (они у вас статически заданы).
То есть если мы ставим задачу как вы, вот так локально бекбоне не нужен, его задача организовать приложение. Такой кусочек выглядит конечно красиво и в реализации прост, но когда стоит реальная задача сделать пусть небольшое но все же реальное приложение с парой форм, списков постраничной навигацией, посути все знакомо и просто, но всплывает достаточно много косячков которые надо фиксить.
На хабре много статей, но вних все красиво )) ибо показывают простое для понимания ночиков.
По вашему примеру хочется заметить что хорошо бы эти окошки как-то хранить в списке (тем более вы андерскор конечно же подключили) чтобы каждый раз не шерстить дом в поисках окна, ну и если уж делать то уходить от ненужного прописывания стилей. все помаксимому в css стили в js коде делаеют его менее читаемым это я про position, width, height (они у вас статически заданы).
Цель статьи как раз в том и состоит, чтобы показать как решается одна простенькая но вполне часто встречающаяся задачка, более полный обзор возможностей я уже писал.
Мне кажется, что так лучше и понятнее для начинающих, чем демонстрировать груды «реальноработающего» кода.
Понятно, что это всего лишь часть системы и есть много различных аспектов работы с backbone, но почему бы не начать с вьюх? Тем более, что тут можно сразу заценить результат
Мне кажется, что так лучше и понятнее для начинающих, чем демонстрировать груды «реальноработающего» кода.
Понятно, что это всего лишь часть системы и есть много различных аспектов работы с backbone, но почему бы не начать с вьюх? Тем более, что тут можно сразу заценить результат
ну статей просто «backbone для начинающих» на храбре много, и пообные примеры есть, когда я столкнулся с реальной задачей ни одна из них не подошла и не оказала какой-либо существеной помощи. ))
Имхо лучше сразу взять не тривиальную задачу и начать её реализовывать в цикле статей.
Имхо лучше сразу взять не тривиальную задачу и начать её реализовывать в цикле статей.
Можно узнать, что это была за задача?
А на счет того что статей много, я вот например не видел на хабре рецептов по организации наследования в backbone, так что надеюсь кому-нибудь статья поможет.
Эм… вы знаете способ кроме var PopupView = Backbone.View.extend ?? помоему это в каждой статье.
Ну скажем задача когда есть много форм для сохранения данных, а также списки этих данных. Скажем есть форма заказов, тут мы редактируем заказы или создаем новый, есть список с этими заказами с постраничным разбиением, форм много, нужна нормальная валидация, данные могу быть вложенными скажем структура
order {
uid: 2,
adress: {
street: "", house: ""
}
}
скажем достучаться до street не тривиально, и конечно я не хочу для каждой формы ручками писать parse и из html данные в модель переносить, хочется автоматизации этого.
Ну скажем задача когда есть много форм для сохранения данных, а также списки этих данных. Скажем есть форма заказов, тут мы редактируем заказы или создаем новый, есть список с этими заказами с постраничным разбиением, форм много, нужна нормальная валидация, данные могу быть вложенными скажем структура
order {
uid: 2,
adress: {
street: "", house: ""
}
}
скажем достучаться до street не тривиально, и конечно я не хочу для каждой формы ручками писать parse и из html данные в модель переносить, хочется автоматизации этого.
я про наследование от собственных вьюх, типа var ChildPopupView = PopupView.extend
Для меня этот момент был не очевиден. На моем первом проекте все вьюхи наследовались напрямую от Backbone.View, так что я решил написать об этом.
По поводу задачи, ну это просто какой-то бла-бла-бла, я если честно не понял в чем проблема… Если считаешь что тут есть какие-то принципиальные трудности, ну напиши об этом сам, порадуй людей.
На счет реальных сложностей с которыми я сталкивался, есть проблема с подключением шаблонов хранящихся в отдельных файлах, нчтоб решить эту задачу я немало времени убил, вот на эту тему пожалуй напишу как-нибудь.
Для меня этот момент был не очевиден. На моем первом проекте все вьюхи наследовались напрямую от Backbone.View, так что я решил написать об этом.
По поводу задачи, ну это просто какой-то бла-бла-бла, я если честно не понял в чем проблема… Если считаешь что тут есть какие-то принципиальные трудности, ну напиши об этом сам, порадуй людей.
На счет реальных сложностей с которыми я сталкивался, есть проблема с подключением шаблонов хранящихся в отдельных файлах, нчтоб решить эту задачу я немало времени убил, вот на эту тему пожалуй напишу как-нибудь.
что значит шаблоны в отделных файлах?
У меня вообще каждая модель в своем файле также как и вьюшка и шаблон, потом все автоматически илдится и для продакшена в сжатом виде выкладывается для девелопмента в не сжатом.
У меня вообще каждая модель в своем файле также как и вьюшка и шаблон, потом все автоматически илдится и для продакшена в сжатом виде выкладывается для девелопмента в не сжатом.
Jquery UI предлагает отличное решение наследования, и с лихвой заменяет view от Bb. см. коммент
А подключение шаблонов на 5 решается с пом. require.js
Вообще вот эта статья проливает свет на многие тонкости и показывает хорошие практики.
А подключение шаблонов на 5 решается с пом. require.js
Вообще вот эта статья проливает свет на многие тонкости и показывает хорошие практики.
В дополнение к комментарию выше.
Еще лучше завести модель для попапов, чтобы хранить их свойства и список окон хранить в коллекции. Тогда легко и логично можно реализовать методы для выбора, например, всех неактивных окон.
В таком виде статья затрагивает только такую сторону backbone, как View, а модели и коллекции остаются в стороне.
С другой стороны, если бы я только начинал изучать backbone, то вы бы мне очень помогли :)
Еще лучше завести модель для попапов, чтобы хранить их свойства и список окон хранить в коллекции. Тогда легко и логично можно реализовать методы для выбора, например, всех неактивных окон.
В таком виде статья затрагивает только такую сторону backbone, как View, а модели и коллекции остаются в стороне.
С другой стороны, если бы я только начинал изучать backbone, то вы бы мне очень помогли :)
>Еще лучше завести модель для попапов
На мой взгляд — это спорное решение. Я считаю, в моделях всетаки должны храниться сущности предметной области, а попап — только один из способов представления модели или списка моделей. В моем последнем проекте куча попапов и там рендерится все подряд, к примеру попап для отправки приглашения выглядит как-то так:
Тут все понятно, для юзеров и ивентов естественно есть модели, но хранить свойства попапа в модели имхо немного странно.
На мой взгляд — это спорное решение. Я считаю, в моделях всетаки должны храниться сущности предметной области, а попап — только один из способов представления модели или списка моделей. В моем последнем проекте куча попапов и там рендерится все подряд, к примеру попап для отправки приглашения выглядит как-то так:
var invitationPopup = new InvitationPopupView({
user: app.user,
invitedUser: this.selectedUser,
event: this.currentEvent
});
Тут все понятно, для юзеров и ивентов естественно есть модели, но хранить свойства попапа в модели имхо немного странно.
Кстати, я наверно воспользуюсь идеей хранения отдельного списка окон. Только наверно лучше будет реализовать его как хеш с z-index-ами в качестве ключей, так всякие «всплывания» будут прозрачнее выглядеть.
Использование моделей для таких сущностей, как окна, оправдывается легкостью передачи событий между окном и контроллером окон (коллекцией, в простом случае). Достаточно в обработчике клика по закрывающей кнопке в окне написать this.model.trigger('closed'), и контроллер окон, например, выведет на передний план другое окно.
Вешать обработчик и триггер непосредственно на сам View сработает не всегда, да и в документации по backbone методы .bind() и .trigger() оговорены только для моделей и коллекций.
Вешать обработчик и триггер непосредственно на сам View сработает не всегда, да и в документации по backbone методы .bind() и .trigger() оговорены только для моделей и коллекций.
Офтоп — как вам кстати новый логотип backbone? :)
Мне неочень как-то
Мне неочень как-то
Вопрос. Для темплейтов можно src применять?
К сожалению напрямую нет. Контент подключенного файла прочитать нельзя.
Мне вообще не понятна традиция хранить темплейты в script-тегах. В теле хтмл-страницы делаю
и никаких лишних обращений к DOM (разумеется, если размер и количество шаблонов на мешает держать их в переменной).
var templates = {
"template.html": "template_string",
"other_template.html": "other_template_string",
…
}
и никаких лишних обращений к DOM (разумеется, если размер и количество шаблонов на мешает держать их в переменной).
Когда шаблоны делает верстальщик, приходится писать скрипт чтоб эскейпить всякую фигню…
Простите template_string это html? а если там 20-30 строк кода вы в конец не запутаетесь? по мне так 5 строк уже плохо!
а чем вам дом не нравиться? Что за обращения к дому? вы о чем? Где тут экономия, на 1 шаблон 1 обращение к дому, а далее уже скомпилиный шаблон надо хранить, потери нулевые.
не виу смысла в подобной каше, а 2-3 тега можно и без шаблона написать если коротко
а чем вам дом не нравиться? Что за обращения к дому? вы о чем? Где тут экономия, на 1 шаблон 1 обращение к дому, а далее уже скомпилиный шаблон надо хранить, потери нулевые.
не виу смысла в подобной каше, а 2-3 тега можно и без шаблона написать если коротко
На практике зачастую этот код собирается на сервере. На стороне сервера, разумеется, следует организовать код таким образом, чтобы не запутаться. На текущем проекте у меня это django-тег, который читает содержимое файлов из папки и пакует/эскейпит их в var templates = {}
В памяти строку шаблона вы в любом случае держите, но в описанном мной случае вы не обращаетесь к дому, чтобы извлечь шаблоны в js-переменную, т.к. они уже изначально там.
В памяти строку шаблона вы в любом случае держите, но в описанном мной случае вы не обращаетесь к дому, чтобы извлечь шаблоны в js-переменную, т.к. они уже изначально там.
И зачем это? Повторяю свой вопрос. Что вы экономите и зачем html хранить в переменно? Что вы экономите, я вам скажу что идею хранить его в тегах скрипт придумали не глупые люди и они не предполагали что вы будите каждый раз от туда их цеплять а сделаете по дом реди примерно следующее
App.Templates.Customers = _.template($('#customers-template').html());
и теперь в App.Templates.Customers у меня лежит уже скомпилиный шаблон который я могу юзать сколько угодно раз, зачем чем нме еще исходный html в переменно, тепе более
_.template() тоже тратит время на компиляцию шаблона если что.
так что наглядней хранить все в скрит и как писали эскейпить не надо ничего, и производительность не падает
App.Templates.Customers = _.template($('#customers-template').html());
и теперь в App.Templates.Customers у меня лежит уже скомпилиный шаблон который я могу юзать сколько угодно раз, зачем чем нме еще исходный html в переменно, тепе более
_.template() тоже тратит время на компиляцию шаблона если что.
так что наглядней хранить все в скрит и как писали эскейпить не надо ничего, и производительность не падает
Используйте require.js для этих целей. Крайне рекомендую.
Спасибо, знаем :) В условиях приложения, для которого http-запросы дешевле оперативной памяти, require.js действительно облегчает работу.
Так компилятор же есть для продакшна :)
Я о том, что даже один лишний запрос бывает критичен и есть смысл передать клиенту все, что можно, в теле основного http-ответа.
Как уже сказали выше, нельзя.
Сегодня на dailyjs была ссылка на молодой, но довольно интересный проект www.eslinstructor.net/vktemplate/ Выглядит очень вкусно, как и шаблоны underscore позволяет использовать js вставки, но к сожалению или с счастью он асинхронный и для backbone его не слишком удобно использовать, хотя и вполне возможно, т. к. для событий во View используется делегирование.
Сегодня на dailyjs была ссылка на молодой, но довольно интересный проект www.eslinstructor.net/vktemplate/ Выглядит очень вкусно, как и шаблоны underscore позволяет использовать js вставки, но к сожалению или с счастью он асинхронный и для backbone его не слишком удобно использовать, хотя и вполне возможно, т. к. для событий во View используется делегирование.
А почему вы решили использовать бэкбон вью для целей создания попапов, вместо того чтобы сделать виджет от jquery-ui? Ведь аналоги полные, только у виджетов шире возможности:
— удобный механизм наследования
— возможность расширения от ui.mouse, что даст возможность обработки drag/drop
— удобная работа с options — фактически, они отражают состояние объекта, чего надо имплементить самому во view
— внешнее API, доступное через элемент, на которого навесили виджет
— события jquery, т.е. штатные, в отличие от предлагаемых бэкбоном
Из недостатков Bb view — невозможность в объекте events навязать действия на внешние события, происходящие за пределами элемента самого view. Плюс в этот-же объект неудобно впихивать реакцию на hotkeys — хотя для этого есть сторонние решения.
Была схожая с вашей задача, решил использовать jquery-ui виджеты вместо Backbone view-ов, посчитал, что так выгоднее — так и оказалось.
— удобный механизм наследования
— возможность расширения от ui.mouse, что даст возможность обработки drag/drop
— удобная работа с options — фактически, они отражают состояние объекта, чего надо имплементить самому во view
— внешнее API, доступное через элемент, на которого навесили виджет
— события jquery, т.е. штатные, в отличие от предлагаемых бэкбоном
Из недостатков Bb view — невозможность в объекте events навязать действия на внешние события, происходящие за пределами элемента самого view. Плюс в этот-же объект неудобно впихивать реакцию на hotkeys — хотя для этого есть сторонние решения.
Была схожая с вашей задача, решил использовать jquery-ui виджеты вместо Backbone view-ов, посчитал, что так выгоднее — так и оказалось.
А зачем вы оборачиваете this.el в $? Разве это уже не jquery wrapped set?
Sign up to leave a comment.
Практическое применение Backbone.View