Cвязывание данных в JavaScript-приложениях: автороутинг событий

[Gasoid]

а для чего это делалось?

[Scalar]

Целью было уменьшить количество кода и упростить создание новых объектов и элементов интерфейса.

[vittore]

к похожему подходу пришли в конце концов при написании сложного редактора

[zandroid]

Если уж есть возможность использовать jQuery (насколько я понял из примеров, это именно оно), то почему не использовать .delegate()?

[Scalar]

Цитата:

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

Зачем же использовать live или delegate, если события можно направлять объектам автоматически, без ручного назначения большого числа обработчиков?

[zandroid]

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

[Scalar]

Спасибо, но я знаю как работает delegate. В топике изложено в основном про удобство и уменьшение кода.
События можно назначить как угодно (и delegate тоже сойдет вместо addEventListener), вопрос в количестве: назначать для каждого типа элементов в отдельности или один раз и навсегда.

Про кроссбраузерность вы конечно правы.

[zandroid]

delegate надо не вместо addEventListener, а вместо вашего Init. Или нужно пример кода привести?

[Scalar]

Нет, спасибо, я понял, я примерно это и имел ввиду.

[AlexTikhonov]

А как насчет Knockout? Вроде неплохая имплементация observable. Писанины тоже не много. При желании можно связать с Now.JS для сохранения значений на сервере.

А по поводу

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

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

[Scalar]

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

[AlexTikhonov]

Сочувствую. Это действительно большая проблема многих компаний, которые не имея хорошего UI-специалиста считают что они отлично знают то, как удобней всего работать конечным пользователям системы.

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

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

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

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

ПС. В любом случае Knockout может неплохо помочь. Если нет желания писать биндинг для каждого контрола, можно при построении UI просто автоматически используя вьюмодель забиндить контролы используя какую-то эвристику (типа символа "_" в id-шках).

[theifish]

Под впечатлением от 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.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.

[k12th]

Мне кажется, что каждый контрол/виджет должен сам отвечать за события, просходящие внутри него. Так легче тестировать, так как каждый виджет получается самодостаточным.