Comments 42
Никак не могу понять, почему так усложнилась работа с пользовательским интерфейсом.
Тот же нокаут и бекбоун требуют столько лишнего кода…
Когда уже сделают нормальный фреймворк на data атрибутах моделью которого будет служить dom?
А то выходит 3 разных модели (dom + js framework model + server database model) и все друг с другом надо подружить…
А что не то? Могут знающие люди посоветовать хороший расширяемый фреймоврк? В js я всего минут пять как не новичок, пока остановился на Backbone.js, но Angular виглядит интересно способом привязывать код к DOM

Есть ли какие нибуть существенные минусы?

Хочется фреймворк с удобным движком, но не жесткий, а такой, чтобы можно было вставить кастомный скрипт за 5 минут в любое место
Каждый фреймворк по своему хорош и стоит делать выбор только опираясь на нужный функционал.
Angular не очень хорошо подходит для приложений, где будет много работы с DOM. Не то что бы это нельзя будет реализовать, можно, просто будет геморойно. А Backbone подойдет.
К тому же, совсем недавно, Jeremy Ashkenas обновил документацию:
Backbone is a library, not a framework, and plays well with others.
Angular не очень хорошо подходит для приложений, где будет много работы с DOM. Не то что бы это нельзя будет реализовать, можно, просто будет геморойно.

Вы бы не могли раскрыть свою мысль? Что за приложения? В чем геморойность?
В общем не подходит оно.
Вот хотелось мне сделать простой интерфейс — таблица и по ней работа с формой. Решил я на свою головую использовать jquery + jqui…
В общем вышла простыня кода, большую часть которого можно было обрезать (всякие вложения closures functions)
Код нечитабелен нормальным человеком. Учитывая что серверная часть пишется на python (Серверная часть и api уже готовы!!!) диссонанс происходящего убивает…
В итоге пришел к выводу: каждой кнопке назначил дата атрибут (то что делает кнопка), table data-attributes дал знать имена tr data атрибутов (т.к. jquery не поддерживает data атрибуты и поиск по .* названию тега), в итоге, думал упрощу себе работу. Ан-нет, jquery ajax не любит передавать внешние данные внутрь success,fail,always функций, в итоге все обросло еще и closures.
В общем хотел простую функцию отправки из dom на сервер и вписывания из серверных данных в dom, а получился супер-монстр…
Надеюсь кто-нибудь напишет удобный плагин для jquery типа serverize, который будет отправлять данные из дата атрибутов и получая их расставлять также как и в оригинальном сете.
Честно говоря, если бы поддерживались селекторы по data атрибутам, было бы проще отобрать сиблинги data-name у td элементов и отправить их на сервер без проблем с указанием в табличном элементе назначений. В общем я думаю можно сделать рабочую dom модель данных без лишнего кода, у меня пока что с лишним кодом, но я каждый раз уменьшаю его количество :).
(т.к. jquery не поддерживает data атрибуты и поиск по .* названию тега),


Простите, что? Всё там поддерживается, либо я не понял всю глубину мысли. Приведите пожалуйста пример html и что вы хотите найти.
DOM, вроде как, довольно медленен в работе со своими узлами. К тому же, Нокаут позволяет делать вычисляемые значения, на чистом ДОМе разве можно это реализовать?

Честно говоря, недавно начал работать с Нокаутом и не нарадуюсь.
Это jquery way, расширение возможностей за счет сторонних плагинов, разбросанных по интернету, живущих своей жизнью. Если немного перефразировать, то это называется усиления связности (coupling), а в программировании принято наоборот уменьшать связность (decoupling), но пользователей jquery понять можно, потому что часто это именно пользователи, а не разработчики :) Из-за специфики разработки (обычно крупные проекты, где работает много разработчиков, то есть пихать сюда какие попало плагины не вариант), мне обычно больше симпатизирует вариант когда фреймворк самодостаточен, то есть там есть средства работы с DOM, набор готовых виджетов, возможность использования MVC стиля разработки и тд. В этом случае можно быть уверенным, что все модули фреймворка совместимы между собой в любой момент времени, что поддержкой и развитием занимается одна команда, что не нужно лазить по сети в поисках очередного плагина или его обновления. Такие фреймворки существуют, как минимум это YUI3 и ExtJS (ко второму отношусь без симпатии).
Жесткая (предполагаю что мало кто делает фасад между сторонним плагином и своим проектом, чтобы при необходимости можно было более просто отвязаться от конкретного плагина и заменить другим) завязанность на множество сторонних плагинов живущих своей жизнью, да это связность в моем понимании.
Связность это когда в коде сущности ссылаются друг на друга.

Вызов цепочки site.users.comments является примером связности. Вы не можете изменить отношение user-comments (например на user-blog-comments) не сломав при это вызов такой цепочки. Чем больше таких мест в коде, тем больше связность.
Если все еще не понятно, то я расширил понятие связности, добавив сюда сильную и жесткую завязанность на сторонние библиотеки. Отсутствие жесткой завязанности на сторонние библиотеки в моем понимании это возможность быстро заменить одну реализацию другой реализацией (одну библиотеку на другую).

«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
То есть я сейчас не веду беседу о классическом понимании связности, как пишут в книгах по паттернам, это само собой разумеется.
Мне прекрасно понятно о чем вы толкуете. Но я не понимаю, почему используя jQuery вы «завязываетесь на сторонние библиотеки», а используя YUI3 — нет. YUI3 это такая волшебная штука которая позволяет заменить себя, хм, скажем на ExtJS без строчки кода?

«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.

Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Смысл использования к примеру YUI3 в том что оно позволяет свести использование сторонних плагинов к минимуму. По поводу адаптера и замены реализации библиотек, имелось ввиду что это было бы полезно при исопользовании сторонних плагинов, не входящих в состав основного фреймворка, которые имеют аналоги, но этим никто не занимается, в JS основном везде хардкод, что часто объяснимо (далеко не во всех проектах целесообразно поддерживать структура проекта гибкой). А используя YUI об этом вообще не нужно думать, так как библиотека довольно самодостаточна, это не тоже самое что использовать jquery+backbone+underscore+jqueryui+bootstrap + еще чего-то «модного» найденного в сети.

>>> Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Разумеется, об этом и речь, немного расширил понятие связности только для того чтобы было понятнее что тут она тоже присутствует и это тоже не особо хорошо (я как-то рефакторил большой проект, где разработчики разных поколений пихали туда все что им было по душе, разгребать такое потом не весело).
Backbone.js позволяет вырастить свой фреймворк, не «завязываясь» на чужих решениях чужих задач, внимательно выбирая решение из предложенных или используя свое. В YUI вы форсированы использовать то, что вам дали.

Вам просто попались плохие разработчики (те которые разных поколений).

Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.
>>> Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.

Согласен, это часто зависит от самого проекта. Например на небольших/непродолжительных проектах (которые например никогда не станут например базовым решением, основой для других проектов) можно наоборот обкатывать новые модные плюшки без особых плачевных последствий. Но в основном я работал с Java EE монстрами, наверно это оставило свой след :)
Если пагинация одна — действительно, много лишнего кода. Но если их много, то оказывается, что одному и тому же коду достаточно просто скормить разные темплейты, и его становится меньше
Хотел возмутиться калькой с английского «пагинация»; полез в словарь, действительно в типографике используется такой термин. Wiki
А вы в каком словаре смотрели?

Кстати, «в технике перевода кальку следует отличать от морфологической передачи, когда иноязычное слово транслитерируется с последующим приспособлением его к морфологии родного языка».
Ушакова. Про кальку спасибо, оказывается «насекомое» — калька, а «фрустрация» — нет.
Написали бы лучше подробное описание backbone-relational, в частности как его подружить с require.js без костылей. Ну а в случае с пагинацией, какие рекомендации/требования для RESTfull сервисов (HATEOAS)
Я отказался от relational, так как для больших коллекций оно ну очень тормозное. А что за проблемы с require.js?
Проблемы с областью видимости, приходиться передавать сам класс модели вместо строки с её именем. Способ, когда модель запихивается в словарь exports, почему-то не работает. Ну и приходится переписывать метод fetchRelated.
В свое время я тоже написал digg-style pagination, используя BackboneJS и Twitter Bootsrap. Моя реализация сложнее вашей и опирается на ранее разработанный алгоритм digg-style пагинации для Django.

Ознакомится с моей реализацией на CoffeeScript и посмотреть демо можно здесь.
P.P.S. Если кол-во страниц блока четное число, то переменную range нужно искать по-другому, но в пагинациях используют зачастую нечетное число. — это что за утверждение такое?? (((((-: Я вот могу утверждать обратное: зачастую чётное, так пагинация нужна только со второй страницы (-:
А где работа с коллекцией? Пагинация строится сразу по всей выборке или при нажатии на нужную страницу идёт запрос к серверу?
Для четных уже дописываю.

Вызвать на вывод пагинацию так:
var pagination = new PaginationView({
	link: "#countries/",
	page_count: this.model.pages,
	page_active: this.model.page
});
$(this.el).find("#pagination").html(pagination.render().el);


Route:
"countries/:page": "countries"

Внутри метода идет вызов коллекции с параметром активной страницы, что и передается серверу.
У меня немного странный вопрос: кто-нибудь из разработчиков, которые уже не первый год используют бэкбон, стали бы за свои деньги заказывать на аутсорсе разработку своего проекта на бэкбоне? Если да — почему?
У backbone первый коммит был всего два года назад. Я бы для начала смотрел на код этих разработчиков. Потому что выучить фреймворк — дело выходных. Для получения качетсвенного софта требуется знание ui & design patterns в первую очередь.

А уж backbone, ember, angular или knockout — дело второе.
if (left_dots == true)

Oh, man… Ну и naming conventions всё же camelCase в JS.

this.link = params.link;

Вовсе необязательно это делать. Доступ к значению link можно получить в рендере через this.options.link.
Спасибо, учту! Статья писалась, для тех кому может пригодиться. + для себя, чтоб услышать конструктивной критики, пожеланий. Спасибо еще раз!
Спасибо за статью, но хотелось бы посоветовать Вам глянуть сюда — это компонент Bakbone.Paginator и вот сюда — документация и примеры.
Only those users with full accounts are able to leave comments. Log in, please.