Comments 42
Никак не могу понять, почему так усложнилась работа с пользовательским интерфейсом.
Тот же нокаут и бекбоун требуют столько лишнего кода…
Когда уже сделают нормальный фреймворк на data атрибутах моделью которого будет служить dom?
А то выходит 3 разных модели (dom + js framework model + server database model) и все друг с другом надо подружить…
Тот же нокаут и бекбоун требуют столько лишнего кода…
Когда уже сделают нормальный фреймворк на data атрибутах моделью которого будет служить dom?
А то выходит 3 разных модели (dom + js framework model + server database model) и все друг с другом надо подружить…
Ближе но не то…
А что не то? Могут знающие люди посоветовать хороший расширяемый фреймоврк? В js я всего минут пять как не новичок, пока остановился на Backbone.js, но Angular виглядит интересно способом привязывать код к DOM
Есть ли какие нибуть существенные минусы?
Хочется фреймворк с удобным движком, но не жесткий, а такой, чтобы можно было вставить кастомный скрипт за 5 минут в любое место
Есть ли какие нибуть существенные минусы?
Хочется фреймворк с удобным движком, но не жесткий, а такой, чтобы можно было вставить кастомный скрипт за 5 минут в любое место
Каждый фреймворк по своему хорош и стоит делать выбор только опираясь на нужный функционал.
Angular не очень хорошо подходит для приложений, где будет много работы с DOM. Не то что бы это нельзя будет реализовать, можно, просто будет геморойно. А Backbone подойдет.
К тому же, совсем недавно, Jeremy Ashkenas обновил документацию:
Angular не очень хорошо подходит для приложений, где будет много работы с DOM. Не то что бы это нельзя будет реализовать, можно, просто будет геморойно. А Backbone подойдет.
К тому же, совсем недавно, Jeremy Ashkenas обновил документацию:
Backbone is a library, not a framework, and plays well with others.
В общем не подходит оно.
Вот хотелось мне сделать простой интерфейс — таблица и по ней работа с формой. Решил я на свою головую использовать 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 + 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 модель данных без лишнего кода, у меня пока что с лишним кодом, но я каждый раз уменьшаю его количество :).
А чем вам не подошёл .serialize() или .serializeArray()? Но насколько я помню, он работает только в одну сторону.
(т.к. jquery не поддерживает data атрибуты и поиск по .* названию тега),
Простите, что? Всё там поддерживается, либо я не понял всю глубину мысли. Приведите пожалуйста пример html и что вы хотите найти.
Можно наоборот с помощью D3, приятного вывиха мозга )
UFO just landed and posted this here
Это jquery way, расширение возможностей за счет сторонних плагинов, разбросанных по интернету, живущих своей жизнью. Если немного перефразировать, то это называется усиления связности (coupling), а в программировании принято наоборот уменьшать связность (decoupling), но пользователей jquery понять можно, потому что часто это именно пользователи, а не разработчики :) Из-за специфики разработки (обычно крупные проекты, где работает много разработчиков, то есть пихать сюда какие попало плагины не вариант), мне обычно больше симпатизирует вариант когда фреймворк самодостаточен, то есть там есть средства работы с DOM, набор готовых виджетов, возможность использования MVC стиля разработки и тд. В этом случае можно быть уверенным, что все модули фреймворка совместимы между собой в любой момент времени, что поддержкой и развитием занимается одна команда, что не нужно лазить по сети в поисках очередного плагина или его обновления. Такие фреймворки существуют, как минимум это YUI3 и ExtJS (ко второму отношусь без симпатии).
Простите, что называется связностью?
Жесткая (предполагаю что мало кто делает фасад между сторонним плагином и своим проектом, чтобы при необходимости можно было более просто отвязаться от конкретного плагина и заменить другим) завязанность на множество сторонних плагинов живущих своей жизнью, да это связность в моем понимании.
Связность это когда в коде сущности ссылаются друг на друга.
Вызов цепочки site.users.comments является примером связности. Вы не можете изменить отношение user-comments (например на user-blog-comments) не сломав при это вызов такой цепочки. Чем больше таких мест в коде, тем больше связность.
Вызов цепочки site.users.comments является примером связности. Вы не можете изменить отношение user-comments (например на user-blog-comments) не сломав при это вызов такой цепочки. Чем больше таких мест в коде, тем больше связность.
Если все еще не понятно, то я расширил понятие связности, добавив сюда сильную и жесткую завязанность на сторонние библиотеки. Отсутствие жесткой завязанности на сторонние библиотеки в моем понимании это возможность быстро заменить одну реализацию другой реализацией (одну библиотеку на другую).
«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
То есть я сейчас не веду беседу о классическом понимании связности, как пишут в книгах по паттернам, это само собой разумеется.
Мне прекрасно понятно о чем вы толкуете. Но я не понимаю, почему используя jQuery вы «завязываетесь на сторонние библиотеки», а используя YUI3 — нет. YUI3 это такая волшебная штука которая позволяет заменить себя, хм, скажем на ExtJS без строчки кода?
Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Смысл использования к примеру YUI3 в том что оно позволяет свести использование сторонних плагинов к минимуму. По поводу адаптера и замены реализации библиотек, имелось ввиду что это было бы полезно при исопользовании сторонних плагинов, не входящих в состав основного фреймворка, которые имеют аналоги, но этим никто не занимается, в JS основном везде хардкод, что часто объяснимо (далеко не во всех проектах целесообразно поддерживать структура проекта гибкой). А используя YUI об этом вообще не нужно думать, так как библиотека довольно самодостаточна, это не тоже самое что использовать jquery+backbone+underscore+jqueryui+bootstrap + еще чего-то «модного» найденного в сети.
>>> Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Разумеется, об этом и речь, немного расширил понятие связности только для того чтобы было понятнее что тут она тоже присутствует и это тоже не особо хорошо (я как-то рефакторил большой проект, где разработчики разных поколений пихали туда все что им было по душе, разгребать такое потом не весело).
>>> Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Разумеется, об этом и речь, немного расширил понятие связности только для того чтобы было понятнее что тут она тоже присутствует и это тоже не особо хорошо (я как-то рефакторил большой проект, где разработчики разных поколений пихали туда все что им было по душе, разгребать такое потом не весело).
Backbone.js позволяет вырастить свой фреймворк, не «завязываясь» на чужих решениях чужих задач, внимательно выбирая решение из предложенных или используя свое. В YUI вы форсированы использовать то, что вам дали.
Вам просто попались плохие разработчики (те которые разных поколений).
Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.
Вам просто попались плохие разработчики (те которые разных поколений).
Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.
>>> Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.
Согласен, это часто зависит от самого проекта. Например на небольших/непродолжительных проектах (которые например никогда не станут например базовым решением, основой для других проектов) можно наоборот обкатывать новые модные плюшки без особых плачевных последствий. Но в основном я работал с Java EE монстрами, наверно это оставило свой след :)
Согласен, это часто зависит от самого проекта. Например на небольших/непродолжительных проектах (которые например никогда не станут например базовым решением, основой для других проектов) можно наоборот обкатывать новые модные плюшки без особых плачевных последствий. Но в основном я работал с Java EE монстрами, наверно это оставило свой след :)
Если пагинация одна — действительно, много лишнего кода. Но если их много, то оказывается, что одному и тому же коду достаточно просто скормить разные темплейты, и его становится меньше
Хотел возмутиться калькой с английского «пагинация»; полез в словарь, действительно в типографике используется такой термин. Wiki
Написали бы лучше подробное описание backbone-relational, в частности как его подружить с require.js без костылей. Ну а в случае с пагинацией, какие рекомендации/требования для RESTfull сервисов (HATEOAS)
Я отказался от relational, так как для больших коллекций оно ну очень тормозное. А что за проблемы с require.js?
Вы код смотрели? Это кошмар :-).
В свое время я тоже написал digg-style pagination, используя BackboneJS и Twitter Bootsrap. Моя реализация сложнее вашей и опирается на ранее разработанный алгоритм digg-style пагинации для Django.
Ознакомится с моей реализацией на CoffeeScript и посмотреть демо можно здесь.
Ознакомится с моей реализацией на CoffeeScript и посмотреть демо можно здесь.
P.P.S. Если кол-во страниц блока четное число, то переменную range нужно искать по-другому, но в пагинациях используют зачастую нечетное число. — это что за утверждение такое?? (((((-: Я вот могу утверждать обратное: зачастую чётное, так пагинация нужна только со второй страницы (-:
А где работа с коллекцией? Пагинация строится сразу по всей выборке или при нажатии на нужную страницу идёт запрос к серверу?
А где работа с коллекцией? Пагинация строится сразу по всей выборке или при нажатии на нужную страницу идёт запрос к серверу?
Для четных уже дописываю.
Вызвать на вывод пагинацию так:
Route:
Внутри метода идет вызов коллекции с параметром активной страницы, что и передается серверу.
Вызвать на вывод пагинацию так:
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"
Внутри метода идет вызов коллекции с параметром активной страницы, что и передается серверу.
У меня немного странный вопрос: кто-нибудь из разработчиков, которые уже не первый год используют бэкбон, стали бы за свои деньги заказывать на аутсорсе разработку своего проекта на бэкбоне? Если да — почему?
if (left_dots == true)
Oh, man… Ну и naming conventions всё же camelCase в JS.
this.link = params.link;
Вовсе необязательно это делать. Доступ к значению link можно получить в рендере через this.options.link.
Sign up to leave a comment.
Пагинация для Backbone.js