Comments 14
а для чего это делалось?
к похожему подходу пришли в конце концов при написании сложного редактора
Если уж есть возможность использовать jQuery (насколько я понял из примеров, это именно оно), то почему не использовать .delegate()?
Цитата:
У нас останется только одна проблема: большое количество кода назначения обработчиков событий, ведь для каждого типа элементов интерфейса нам придется назначить отдельный обработчик для каждого события! Итого количество назначений будет равно = кол-во объектов Х количество элементов Х количество событий.
Зачем же использовать live или delegate, если события можно направлять объектам автоматически, без ручного назначения большого числа обработчиков?
У нас останется только одна проблема: большое количество кода назначения обработчиков событий, ведь для каждого типа элементов интерфейса нам придется назначить отдельный обработчик для каждого события! Итого количество назначений будет равно = кол-во объектов Х количество элементов Х количество событий.
Зачем же использовать live или delegate, если события можно направлять объектам автоматически, без ручного назначения большого числа обработчиков?
Между прочим, .delegate() как раз и основан на «свойстве событий в DOM: захват и всплытие» и можно его вызвать на том же body. А от его использования у вас код получится кроссбраузерный (т.е. будет работать и в IE<9) — почитайте описание, я зря ссылку дал что ли?
Спасибо, но я знаю как работает delegate. В топике изложено в основном про удобство и уменьшение кода.
События можно назначить как угодно (и delegate тоже сойдет вместо addEventListener), вопрос в количестве: назначать для каждого типа элементов в отдельности или один раз и навсегда.
Про кроссбраузерность вы конечно правы.
События можно назначить как угодно (и delegate тоже сойдет вместо addEventListener), вопрос в количестве: назначать для каждого типа элементов в отдельности или один раз и навсегда.
Про кроссбраузерность вы конечно правы.
А как насчет Knockout? Вроде неплохая имплементация observable. Писанины тоже не много. При желании можно связать с Now.JS для сохранения значений на сервере.
А по поводу
тоже есть интересное замечание — вот Вам, как разработчику, сложно вешать обработчики из-за того что в UI может быть много элементов. А Вы подумайте как будет пользователю, если его загрузят не меньшим количеством элементов? :) Как альтернатива использовать концепцию task-based UI, в котором существенно уменьшается количество контролов, и идет основная «заточка» на бизнес-значения действий пользователя. Что уменьшает количество возможных действий пользователя (а, в итоге, и количество контролов), но придет смысл действиям. Не надо делать «умный ексель», а лучше сделать минимальный интерфейс, в котором пользователь сможет сделать именно (и только) то, для чего создано ваше приложение.
А по поводу
У нас останется только одна проблема: большое количество кода назначения обработчиков событий, ведь для каждого типа элементов интерфейса нам придется назначить отдельный обработчик для каждого события!
тоже есть интересное замечание — вот Вам, как разработчику, сложно вешать обработчики из-за того что в UI может быть много элементов. А Вы подумайте как будет пользователю, если его загрузят не меньшим количеством элементов? :) Как альтернатива использовать концепцию task-based UI, в котором существенно уменьшается количество контролов, и идет основная «заточка» на бизнес-значения действий пользователя. Что уменьшает количество возможных действий пользователя (а, в итоге, и количество контролов), но придет смысл действиям. Не надо делать «умный ексель», а лучше сделать минимальный интерфейс, в котором пользователь сможет сделать именно (и только) то, для чего создано ваше приложение.
Я бы рад сделать интерфейс простым, понятным и минималистичным. Но в самом начале топика я написал, что рассматриваю заведомо очень большой и функциональный интерфейс, и именно таково было требование заказчика (т.е. пользователя) — что бы все было под рукой, и в один клик можно было совершить десяток различных действий. В моем случае это большая редакционно-издательская система подготовки контента для позновательного геолокационного сервиса.
Сочувствую. Это действительно большая проблема многих компаний, которые не имея хорошего UI-специалиста считают что они отлично знают то, как удобней всего работать конечным пользователям системы.
Я сам работаю с огромной бухгалтерской системой с поддержкой разных европейских законодательств. И наблюдаю ту же самую картинку — люди привыкли что бухгалтера работают с бланками (т.е. почти всегда с «формой» с несколько десятками инпутов). Но в Европе все больше и больше переходят на электронную отчетность. В результате бухгалтеру показывается все те же десятки контролов, зато супер-интеллектуальные (типа красивый выбор счета-под.счета, налога, и т.д.) — т.е. фактически тот же «бланк» но умный.
И вместо того, чтоб спросить у бухгалтера пару циферок при осуществлении элементарной проводки, которую он делает сотню раз в день просто две-три циферки, ему вываливают все эту огромную форму (да, с многими заполненными полями).
К сожалению не могу Вам дать рекомендацию, так как не знаю домена Вашего приложения, но уверен что всегда можно проанализировать основные действия пользователей системы, и выделить несколько задач (tasks/activities), на основе которых уже и построить интерфейс.
Действительно жаль, что все еще много застарелых бывших менеджеров, которые считают что они знают все и как лучше, и просто отказываются смотреть на тенденции развития современных интерфейсов.
ПС. В любом случае Knockout может неплохо помочь. Если нет желания писать биндинг для каждого контрола, можно при построении UI просто автоматически используя вьюмодель забиндить контролы используя какую-то эвристику (типа символа "_" в id-шках).
Я сам работаю с огромной бухгалтерской системой с поддержкой разных европейских законодательств. И наблюдаю ту же самую картинку — люди привыкли что бухгалтера работают с бланками (т.е. почти всегда с «формой» с несколько десятками инпутов). Но в Европе все больше и больше переходят на электронную отчетность. В результате бухгалтеру показывается все те же десятки контролов, зато супер-интеллектуальные (типа красивый выбор счета-под.счета, налога, и т.д.) — т.е. фактически тот же «бланк» но умный.
И вместо того, чтоб спросить у бухгалтера пару циферок при осуществлении элементарной проводки, которую он делает сотню раз в день просто две-три циферки, ему вываливают все эту огромную форму (да, с многими заполненными полями).
К сожалению не могу Вам дать рекомендацию, так как не знаю домена Вашего приложения, но уверен что всегда можно проанализировать основные действия пользователей системы, и выделить несколько задач (tasks/activities), на основе которых уже и построить интерфейс.
Действительно жаль, что все еще много застарелых бывших менеджеров, которые считают что они знают все и как лучше, и просто отказываются смотреть на тенденции развития современных интерфейсов.
ПС. В любом случае Knockout может неплохо помочь. Если нет желания писать биндинг для каждого контрола, можно при построении UI просто автоматически используя вьюмодель забиндить контролы используя какую-то эвристику (типа символа "_" в id-шках).
Под впечатлением от Knockout для одного своего проекта я написал свой упрощённый велосипед, заточенный только под jQuery: jumpkot.com/js/observable.js, цель была в том, чтобы автоматом собрать нужные DOM-элементы в обёртке jQuery ну и попутно назначить какие-то экшны.
Например, для HTML-кода:
Можно сделать так:
После чего в App.ob.main.place мы получим наш div, а для h1 на клик повесится события App.hide.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.
Например, для 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.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.
Мне кажется, что каждый контрол/виджет должен сам отвечать за события, просходящие внутри него. Так легче тестировать, так как каждый виджет получается самодостаточным.
Sign up to leave a comment.
Cвязывание данных в JavaScript-приложениях: автороутинг событий