Обработчики в js

Destrifer · January 13, 2009

Как я понял:

1.Если просто переназначить обработчики через JS, то они не срабатывают, если-же поместить их в функцию, срабатывающую, скажем, по onload, объявленный через атрибут, то мы возвращаемся к тому, с чего начали.

2.Если на таком обработчике висит функция, то передать значение в неё не предсталяется возможным, кроме как, повесив отдельную функцию, через которую вызывается искомая. И так для каждой функции в которую мы передаем значения?

Что-то не совсем понятны плюсы такого подхода.

s0rr0w · January 13, 2009

Destrifer said:
Как я понял:
1.Если просто переназначить обработчики через JS, то они не срабатывают, если-же поместить их в функцию, срабатывающую, скажем, по onload, объявленный через атрибут, то мы возвращаемся к тому, с чего начали.
2.Если на таком обработчике висит функция, то передать значение в неё не предсталяется возможным, кроме как, повесив отдельную функцию, через которую вызывается искомая. И так для каждой функции в которую мы передаем значения?
Что-то не совсем понятны плюсы такого подхода.

ничего не понял...

Searcher · January 13, 2009

Да, совершенно не понятно...

Поставьте четко задачу. В чем проблема?

Destrifer · January 13, 2009

Я по старинке назначаю обработчики через атрибуты соответствующих тегов.

Однако есть вариант прописывать их в JS. Вроде при этом соблюдается семантика кода, идет четкое разделение html, css, js и т.д.

Переназначил их через свойства объектов - а как их проинициализировать? Они работают, скажем, если поместить все в отдельную функцию и ее вызывать по onload в body. Но этот onload приходиться прописывать в атрибутах тега. Т.е. мы опять получаем смешивание js и html?

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

В этом и проблема. Может я неправ?

s0rr0w · January 13, 2009

Destrifer said:
Я по старинке назначаю обработчики через атрибуты соответствующих тегов.
Однако есть вариант прописывать их в JS. Вроде при этом соблюдается семантика кода, идет четкое разделение html, css, js и т.д.
Переназначил их через свойства объектов - а как их проинициализировать? Они работают, скажем, если поместить все в отдельную функцию и ее вызывать по onload в body. Но этот onload приходиться прописывать в атрибутах тега. Т.е. мы опять получаем смешивание js и html?
Дальше - больше. Если на обработчик прописанный в атрибутах тега я легко мог повесить функцию и передать в нее значение, то при объявлении его через свойства, передать значение в функцию уже не получится. Единственный вариант приходящий в голову - это поместить функцию с передаваемым параметром в другую функцию (не передающую ничего), и её уже вешать на обработчик. И так с каждым обработчиком??
В этом и проблема. Может я неправ?

Ааа.... Да, это старый добрый прикол. True-программеры парят себе мозг с абсолютно неудобным механизмом even listener'ов, хотя старый добрый onclick решает куда лучше поставленную задачу.

Передача параметров через eventListener возможна путем создания анонимной функции-обертки.

function(){

foo( 1 );

}

Тело этой анонимной функции и есть тело onclick-обработчика.

Вынесение обрабочиков за пределы HTML кода считаю неудобным. Во-первых, изменения, дополнения и удаление кода превращается в кошмар. Шансы написать что-то, что будет приводить к ошибкам, неимоверно высоки. Вместо того, чтобы прочитать в одном месте код, придется читать его в двух местах. Придется делать кучу идентификаторов, что приведет к дополнительным проблемам с уникальностью, или придется написать модуль учета идентификаторов. И все ради чего?

Destrifer · January 13, 2009

Спасибо за развернутый ответ.

s0rr0w said:
И все ради чего?

Есть люди которые "программируют ради программирования". Понять таких мне не дано.

s0rr0w · January 13, 2009

Destrifer said:
Есть люди которые "программируют ради программирования". Понять таких мне не дано.

Забейте. Программирование как искусство никому не нужно. Коммерция берет верх в любом случае.

Вы можете потратить 10 лет на создание "идеального кода", а в итоге он никому не будет интересен кроме вас, а можете заработать миллион, удачно продав сырой продукт в нужный момент времени.

rash · January 13, 2009

s0rr0w said:
Забейте. Программирование как искусство никому не нужно. Коммерция берет верх в любом случае.

Программирование как искусство нужно тем, для кого это хобби. Можно писать посредственные коммерческие программы и "доводить" программы, которые пишутся "для себя", "в стол".

Так что "Программирование как искусство не нужно в коммерции".

s0rr0w · January 13, 2009

rash said:
Программирование как искусство нужно тем, для кого это хобби. Можно писать посредственные коммерческие программы и "доводить" программы, которые пишутся "для себя", "в стол".
Так что "Программирование как искусство не нужно в коммерции".

И много вы видели программистов, которые не преследуют коммерческих целей в написании программ?

Destrifer · January 14, 2009

s0rr0w said:
И много вы видели программистов, которые не преследуют коммерческих целей в написании программ?

А как-же разработчики Open Source?

А также энтузиасты-разработчики написавшые множество небольших но полезных программ?

Врят-ли кнопочка "Donate" способна окупить затраты.

s0rr0w · January 14, 2009

Destrifer said:
А как-же разработчики Open Source?
А также энтузиасты-разработчики написавшые множество небольших но полезных программ?
Врят-ли кнопочка "Donate" способна окупить затраты.

Раскрою вам секрет (страшная тайна)

Большая половина людей в опен-сорс получают зарплаты.

Остальные пишут программы для того, чтобы прославиться и получать зарплаты. Цели меркантильные до ужаса.

Нет денег- нет смысла развивать проект.

ZoNT · January 14, 2009

s0rr0w said:
Большая половина...

Сразу видно, кто тут программист

Почитай вот это: http://forum.htmlbook.ru/index.php?showtopic=12044

SelenIT · January 14, 2009

Quote
Как я понял

Неправильно поняли

Quote
Если просто переназначить обработчики через JS, то они не срабатывают

Прекрасно срабатывают, если к моменту назначения искомые элементы существуют. Если скрипт, по правилам хорошего тона, пишется в <head>, это по понятным причинам не выполняется. Можно писать скрипт с назначением обработчиков в конце <body>, но лучше действительно вешать на событие загрузки.

Quote
если-же поместить их в функцию, срабатывающую, скажем, по onload, объявленный через атрибут

Зачем?

window.onload = init;

Quote
Если на таком обработчике висит функция, то передать значение в неё не предсталяется возможным, кроме как, повесив отдельную функцию, через которую вызывается искомая.

Во-первых, у ф-ции есть массив arguments, ее не обязательно вызывать с тем же кол-вом параметров, с каким она объявлена. Во-вторых, данные можно передавать не только аргументами, но и через свойства любых объектов, в т.ч. самой ф-ции. В-третьих, хороший обработчик и не должен зависеть от левой информации, которую нельзя получить из свойств самого события (event) и вызвавшего его объекта (event.target||event.srcElement)... хотя последнее - мое имхо

Quote
не совсем понятны плюсы такого подхода

Воспользуйтесь поиском по фразе "ненавязчивый (unobtrusive) Javascript".

Destrifer · January 14, 2009

s0rr0w said:
Цели меркантильные до ужаса.

Где-то в глубине души я предполагал что это, увы, так. Хотя вера в человечество не хотела так бысто сдаваться.

2SelenIT:

Спасибо за дополнения. Открыл для себя много нового

s0rr0w · January 14, 2009

ZoNT said:
Сразу видно, кто тут программист
Почитай вот это: http://forum.htmlbook.ru/index.php?showtopic=12044

И что я должен там прочитать?

ZoNT · January 14, 2009

s0rr0w said:
И что я должен там прочитать?

Правила русского языка.

s0rr0w · January 14, 2009

SelenIT said:
Воспользуйтесь поиском по фразе "ненавязчивый (unobtrusive) Javascript".

Почитал

http://habrahabr.ru/blogs/javascript/26152/

Посмеялся над некоторыми моментами.

1. Unobtrusive Javascrit очищает HTML от JS

При этом делая HTML реюзабельным. Появляются уместные классы, уходят дублирующиеся onclick. Верстальщик, не использующий unobtrusive javascript, когда-нибудь сделает из проекта запутанный клубок. Не использовать этот подход в клиентском коде на сегодня равнозначно игнорированию MVC в серверных скриптах.

Использование JS отдельно от HTML удорожает разработку без существенного улучшения качества кода.

Верстальщик, который не умеет думать головой все равно сделает из проекта запутанный клубок. Unobtrusive javascript тут ему не поможет.

Второй и третий пункт перефразирую. Нужно программировать по принципу: построй работу скрипта с абстрактной моделью, не привязываясь к конкретному HTML коду.

4. Способ "а попробуй без JS" позволяет делать много чего корректней и проще

На сегодня яваскрипт настолько развит, что уже не нуждается ни в «form» (для post), ни в «a» (для get) чтобы общаться с сервером.

Ага, особенно что касается передачи файлов. Не нуждается. Ни капли.

5. "а попробуй без JS" позволяет делать много чего юзабильней

Применимо только к классической схеме передвижения по ресурсу. Для Web2.0 ресурсов, которые используют принцип "весь ресурс наодной странице" это правило бесполезно.

6. Используй будущие стандарты уже сегодня.

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

7. Облегчает тестирование с Selenium и другими утилитами.

Не все проекты можно протестировать Selenium'ом.

9. Приложение закончит операцию (хоть как-то) даже если в JS вдруг выскочила ошибка.

Если выскочит хоть какая-то ошибка, то пользователь в 80% случаев гарантированно не станет продолжать дальше работать.

10. Ваше приложение сможет работать при отключенном JS.

Приложение без JS - это прошлый век. Человека, который сознательно отключает JS в приложении, зная, что это приведет к существенному снижению юзабилити, кроме как шизоидальным параноиком с манией преследования, нельзя назвать по другому.

SelenIT · January 14, 2009

s0rr0w, по многим пунктам все-таки можно поспорить

Quote
Использование JS отдельно от HTML удорожает разработку без существенного улучшения качества кода.

И чем же удорожает, например, создание удобной галереи использование вариаций на тему LightBox-а (имхо, удачный пример "ненавязчивости")? По сравнению с нудным копипастом onclick-ов для каждой ссылки?

К тому же можно отлаживать верстку и функционал по раздельности. И показывать заказчику работающую галерею с открывающимися в новом окне картинками и отдельно демку скрипта, а не набор скриншотов "будет вот так, а при нажатии - вот этак"...

Quote
> 7. Облегчает тестирование с Selenium и другими утилитами.
Не все проекты можно протестировать Selenium'ом.

А "другими утилитами"?

Quote
Для Web2.0 ресурсов, которые используют принцип "весь ресурс наодной странице"

Это как? Весь контент по одному адресу? А как поставить закладку, послать ссылку другу, как быть с поисковиками, в конце концов? Есть мнение, что это какой-то неправильный вебдваноль

Quote
Если выскочит хоть какая-то ошибка, то пользователь в 80% случаев гарантированно не станет продолжать дальше работать.

Это если он ее заметит. Но в FF и Опере яваскриптовые ошибки пишутся только в консоль, никак не проявляя себя внешне. В IE по умолчанию тоже всего лишь рисуется желтый треугольник в статусе, куда юзеры не особо смотрят. И если вместо отвалившегося скрипта произойдет умолчательное действие, напр., переход по ссылке, 80% юзеров ничего не заподозрят и решат, что так и надо

.

Quote
Человека, который сознательно отключает JS в приложении, зная, что это приведет к существенному снижению юзабилити, кроме как шизоидальным параноиком с манией преследования, нельзя назвать по другому.

А человека, который пользуется мобильным браузером? Например, Оперой Мини, составляющей (по некоторым оценкам) на сегодняшний день более 15% аудитории по Москве?

Edited January 14, 2009 by SelenIT

s0rr0w · January 14, 2009

SelenIT said:
s0rr0w, по многим пунктам все-таки можно поспорить
И чем же удорожает, например, создание удобной галереи использование вариаций на тему LightBox-а (имхо, удачный пример "ненавязчивости")? По сравнению с нудным копипастом onclick-ов для каждой ссылки?

Галлерея - это примитивный пример. Его не стоит брать как пример ненавязчивого скриптинга. Такой метод логически оправдан.

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

А потом оставьте данный код на пару месяцев и вернитесь к нему. И вы поймете, в чем именно проблема.

Например вот вам код

Какой элемент является ссылкой и сколько onclick-обрабочиков на него повешено?

Quote
К тому же можно отлаживать верстку и функционал по раздельности. И показывать заказчику работающую галерею с открывающимися в новом окне картинками и отдельно демку скрипта, а не набор скриншотов "будет вот так, а при нажатии - вот этак"...

Когда у вас один скрипт, то это одно, а когда у вас их 10? 20?

Quote
А "другими утилитами"?

С тем же самым успехом.

Quote
Это как? Весь контент по одному адресу? А как поставить закладку, послать ссылку другу, как быть с поисковиками, в конце концов? Есть мнение, что это какой-то неправильный вебдваноль

Да без проблем что для одних, что для других.

Quote
Это если он ее заметит. Но в FF и Опере яваскриптовые ошибки пишутся только в консоль, никак не проявляя себя внешне. В IE по умолчанию тоже всего лишь рисуется желтый треугольник в статусе, куда юзеры не особо смотрят. И если вместо отвалившегося скрипта произойдет умолчательное действие, напр., переход по ссылке, 80% юзеров ничего не заподозрят и решат, что так и надо.

Да-да-да. Верю. Фидбэк красный был от одной JS ошибки.

Quote
А человека, который пользуется мобильным браузером? Например, Оперой Мини, составляющей (по некоторым оценкам) на сегодняшний день более 15% аудитории по Москве?

Опера мини достаточно неплохо справляется с JS.

SelenIT · January 14, 2009

Quote
А потом модифицируйте HTML-код одного из них.

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

Quote
Например вот вам код
<div class="menuItem"><span class="menuTitle"><b>Item 1</b></span></div>
Какой элемент является ссылкой и сколько onclick-обрабочиков на него повешено?

Если разработчик нормальный, то по первому пункту div сразу исключаем. Если код взят из проекта с ненавязчивым JS, то ссылки в этом куске нет вообще

Но вообще лично я никогда при отладке скриптов (и даже сложной верстки с их участием) в голый сурс не смотрю — сам знаю, что там может быть много чего не относящегося к действительности. Только дом-инспекторы/файрбаги/девелопер-тулзы из IE8/драгонфлаи и т.п. средства, показывающие актуальное состояние дел. И все обработчики (а заодно — многие косяки самой разметки) находятся куда быстрее, чем при ковырянии в непонятной мешанине языков.

Quote
а когда у вас их 10? 20?

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

Повторюсь, что веду речь о типовых задачах для сайтов "общего назначения" и типовых же админок. Для уникальных веб-интерфейсов к уникальным сложным вещам (уровня GMail'а, вероятно, оправданнее будет подход низкоуровневой ручной работы, с упором на максимальную эффективность.

Quote
без проблем что для одних, что для других

А благодаря чему?

Quote
Фидбэк красный был

Значит, заметили. Видимо, в эту ошибку всё упиралось. Вероятность чего при ненавязчивом подходе гораздо ниже.

Quote
Опера мини достаточно неплохо справляется с JS.

1. С какой версии? 2. Как она это делает (технически)? 3. Насколько "неплохо"? Edited January 14, 2009 by SelenIT

Destrifer · January 15, 2009

SelenIT said:
данные можно передавать не только аргументами, но и через свойства любых объектов, в т.ч. самой ф-ции

Почитал, полистал, погуглил - вроде оно, где-то, витает в воздухе, но ухватить не получается .

Каким образом это осуществляется? Если можно, пример.

s0rr0w · January 15, 2009

SelenIT said:
Ну, уникальный скрипт на уникальной разметке — все-таки вещь штучная, там ручная работа оправдана. Но почему-то мне кажется, что делать в одном проекте два форка одного уже отлаженного компонента с разной разметкой — не лучшая идея в принципе...

Один JS код, много разметок - это норма для любого правильного компонента. Если вам нужно что-то дописать или исправить ошибку, то при нормальном подходе вы сделаете это один раз, а при ненормальном - несколько. Кому это надо?

SelenIT said:
Если разработчик нормальный, то по первому пункту div сразу исключаем. Если код взят из проекта с ненавязчивым JS, то ссылки в этом куске нет вообще

Это все гадание на кофейной гуще. С ненавязчивым подходом, доведенным до абсурда, вам придется внимательно изучать JS код, держа в уме структуру HTML, чтобы ответить на столь примитивный вопрос.

SelenIT said:
Но вообще лично я никогда при отладке скриптов (и даже сложной верстки с их участием) в голый сурс не смотрю — сам знаю, что там может быть много чего не относящегося к действительности. Только дом-инспекторы/файрбаги/девелопер-тулзы из IE8/драгонфлаи и т.п. средства, показывающие актуальное состояние дел. И все обработчики (а заодно — многие косяки самой разметки) находятся куда быстрее, чем при ковырянии в непонятной мешанине языков.

Покажите мне хоть один отладчик, который показывает коллекцию listener'ов.

SelenIT said:
В этом случае как раз оправдано использование фреймворка (чужого или собственного), а нормальные фреймворки как раз поощряют "ненавязчивый" подход. Опять же, все равно никак не пойму, чем отладка 10—20 ненавязчивых скриптов, сгруппированных по функциям и подключаемых в одном месте, труднее отладки 10—20 фрагментированных скриптов, размазанных по всему коду проекта вперемешку с разметкой...

Не надо впадать в крайности. Это основная моя мысль.

SelenIT said:
Повторюсь, что веду речь о типовых задачах для сайтов "общего назначения" и типовых же админок. Для уникальных веб-интерфейсов к уникальным сложным вещам (уровня GMail'а, вероятно, оправданнее будет подход низкоуровневой ручной работы, с упором на максимальную эффективность.

А чем типовые принципиально отличаются от нетиповых?

SelenIT said:
А благодаря чему?

Посмотрите как гмейл работает

SelenIT said:
Значит, заметили. Видимо, в эту ошибку всё упиралось. Вероятность чего при ненавязчивом подходе гораздо ниже.

Да ни во что там не упиралось.

SelenIT said:
1. С какой версии? 2. Как она это делает (технически)? 3. Насколько "неплохо"?

Mini предварительно обрабатывает скрипты на сервере благодаря движку оперы.

Yarik Voronov · January 15, 2009

Destrifer said:
>> данные можно передавать не только аргументами, но и через свойства любых объектов, в т.ч. самой ф-ции
>Почитал, полистал, погуглил - вроде оно, где-то, витает в воздухе, но ухватить не получается .
Каким образом это осуществляется? Если можно, пример.

function My (inp) {
	this.value = inp; // уникальное свойство для нового сконструированного объекта
}
My.prototype = {
	someAction: function () {},
	defaultValues: [1,2] // свойства общие для всех объектов сконструированных My 
}

примерно также можно представить объект html как объект JS, но это грозит серьезными проблемами в IE (более подробно смотрите "утечки памяти IE", "замыкания"). Вот один из вариантов:

var el = document.getElementById('myElement');
el.myaction = function (val) {alert(val)};
el.myvalue = true;
el.myaction  (el.myvalue);

так же смотрите метод [Element].getAttribute("[attributeName]"); Если надо непосредственно через html-код задать какой-либо параметр, а потом его получить в JS. Но. В таком случае html-код уже не будет валидным, если использованы имена атрибутов отличных от указанных в спецификации.

но, имхо, удобнее представлять объекты html, как значение свойств (параметров) объектов JS

s0rr0w · January 16, 2009

Yarik Voronov said:
Но. В таком случае html-код уже не будет валидным, если использованы имена атрибутов отличных от указанных в спецификации.

Это почему?

Yarik Voronov · January 16, 2009

s0rr0w said:
>> Но. В таком случае html-код уже не будет валидным, если использованы имена атрибутов отличных от указанных в спецификации
> Это почему?

Потому что html специализированный язык разметки. То есть строго регламентированный стандартами (HTML 4.01, XHTML 1.0 и прочая) в плане того какие атрибуты есть у того или иного элемента и вообще какие элементы (теги) есть и как они (теги) должны обрабатываться браузерами.

Конечно, html-код c "дополнительными" атрибутами будет правильно отрабатываться браузерами, но не пройдет валидацию на соответствие использованному стандарту (см. DOCTYPE)

З.Ы.: s0rr0w, классно, что вы гордитесь своим статусом "Бестолочи".

s0rr0w · January 16, 2009

Yarik Voronov said:
Потому что html специализированный язык разметки. То есть строго регламентированный стандартами (HTML 4.01, XHTML 1.0 и прочая) в плане того какие атрибуты есть у того или иного элемента и вообще какие элементы (теги) есть и как они (теги) должны обрабатываться браузерами.
Конечно, html-код c "дополнительными" атрибутами будет правильно отрабатываться браузерами, но не пройдет валидацию на соответствие использованному стандарту (см. DOCTYPE)
З.Ы.: s0rr0w, классно, что вы гордитесь своим статусом "Бестолочи".

Да, HTML регламентирован стандартом. XHTML по сути своей является XML приложением, и создавать новые теги и атрибуты можно.

Если рассматривать DOM, как еще один из стандартов, то он не запрещает создавать в дереве кастом атрибуты.

Еще один из приколов конфликта стандартов на примере CSS

<div><a>link</a></div>

div { display: inline }
a { dislpay: block }

С точки зрения механической валидности код валиден на 100%.

С точки зрения рендеринга это невалидный код.

Sign In

Обработчики в js

Question

Link to comment

Share on other sites

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Days

Posted Images

54 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information