Pull to refresh

Comments 14

Целью было уменьшить количество кода и упростить создание новых объектов и элементов интерфейса.
к похожему подходу пришли в конце концов при написании сложного редактора
Если уж есть возможность использовать jQuery (насколько я понял из примеров, это именно оно), то почему не использовать .delegate()?
Цитата:

У нас останется только одна проблема: большое количество кода назначения обработчиков событий, ведь для каждого типа элементов интерфейса нам придется назначить отдельный обработчик для каждого события! Итого количество назначений будет равно = кол-во объектов Х количество элементов Х количество событий.

Зачем же использовать live или delegate, если события можно направлять объектам автоматически, без ручного назначения большого числа обработчиков?
Между прочим, .delegate() как раз и основан на «свойстве событий в DOM: захват и всплытие» и можно его вызвать на том же body. А от его использования у вас код получится кроссбраузерный (т.е. будет работать и в IE<9) — почитайте описание, я зря ссылку дал что ли?
Спасибо, но я знаю как работает delegate. В топике изложено в основном про удобство и уменьшение кода.
События можно назначить как угодно (и delegate тоже сойдет вместо addEventListener), вопрос в количестве: назначать для каждого типа элементов в отдельности или один раз и навсегда.

Про кроссбраузерность вы конечно правы.
delegate надо не вместо addEventListener, а вместо вашего Init. Или нужно пример кода привести?
Нет, спасибо, я понял, я примерно это и имел ввиду.
А как насчет Knockout? Вроде неплохая имплементация observable. Писанины тоже не много. При желании можно связать с Now.JS для сохранения значений на сервере.

А по поводу
У нас останется только одна проблема: большое количество кода назначения обработчиков событий, ведь для каждого типа элементов интерфейса нам придется назначить отдельный обработчик для каждого события!

тоже есть интересное замечание — вот Вам, как разработчику, сложно вешать обработчики из-за того что в UI может быть много элементов. А Вы подумайте как будет пользователю, если его загрузят не меньшим количеством элементов? :) Как альтернатива использовать концепцию task-based UI, в котором существенно уменьшается количество контролов, и идет основная «заточка» на бизнес-значения действий пользователя. Что уменьшает количество возможных действий пользователя (а, в итоге, и количество контролов), но придет смысл действиям. Не надо делать «умный ексель», а лучше сделать минимальный интерфейс, в котором пользователь сможет сделать именно (и только) то, для чего создано ваше приложение.
Я бы рад сделать интерфейс простым, понятным и минималистичным. Но в самом начале топика я написал, что рассматриваю заведомо очень большой и функциональный интерфейс, и именно таково было требование заказчика (т.е. пользователя) — что бы все было под рукой, и в один клик можно было совершить десяток различных действий. В моем случае это большая редакционно-издательская система подготовки контента для позновательного геолокационного сервиса.
Сочувствую. Это действительно большая проблема многих компаний, которые не имея хорошего UI-специалиста считают что они отлично знают то, как удобней всего работать конечным пользователям системы.

Я сам работаю с огромной бухгалтерской системой с поддержкой разных европейских законодательств. И наблюдаю ту же самую картинку — люди привыкли что бухгалтера работают с бланками (т.е. почти всегда с «формой» с несколько десятками инпутов). Но в Европе все больше и больше переходят на электронную отчетность. В результате бухгалтеру показывается все те же десятки контролов, зато супер-интеллектуальные (типа красивый выбор счета-под.счета, налога, и т.д.) — т.е. фактически тот же «бланк» но умный.

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

К сожалению не могу Вам дать рекомендацию, так как не знаю домена Вашего приложения, но уверен что всегда можно проанализировать основные действия пользователей системы, и выделить несколько задач (tasks/activities), на основе которых уже и построить интерфейс.

Действительно жаль, что все еще много застарелых бывших менеджеров, которые считают что они знают все и как лучше, и просто отказываются смотреть на тенденции развития современных интерфейсов.

ПС. В любом случае Knockout может неплохо помочь. Если нет желания писать биндинг для каждого контрола, можно при построении UI просто автоматически используя вьюмодель забиндить контролы используя какую-то эвристику (типа символа "_" в id-шках).
Под впечатлением от Knockout для одного своего проекта я написал свой упрощённый велосипед, заточенный только под jQuery: jumpkot.com/js/observable.js, цель была в том, чтобы автоматом собрать нужные DOM-элементы в обёртке jQuery ну и попутно назначить какие-то экшны.

Например, для HTML-кода:

<body>
<div app-bind='"bind": "main.place"'>
<h1 app-bind='"click": "hide"'>Привет</h1>
</div>
</body>


Можно сделать так:

var App = {
init: function () {
$('body').observable(this);
},

hide: function () {$(this).hide()}
}
$(function() {App.init()});


После чего в App.ob.main.place мы получим наш div, а для h1 на клик повесится события App.hide.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.
Мне кажется, что каждый контрол/виджет должен сам отвечать за события, просходящие внутри него. Так легче тестировать, так как каждый виджет получается самодостаточным.
Only those users with full accounts are able to leave comments. Log in, please.