ArbNet#: Сейчас у меня замена меток происходит через функцию модуля работы с элементами. Но вот думается может эти функции внедрить в модуль юнита, чтобы через функцию юнита модифицировать макет и запускать открытие диалога и тд
Не видя проект сложно понять о чём речь, но могу подсказать из чего исходить. Не помню, как это называется в терминологии smell code - когда класс выполняет работу другого класса и обращается к его методам. В любом случае отталкиваетесь от обратного: конкретные функции должны быть у того модуля, который непосредственно работает с объектом.
Не знаю, мне кажется вещь хоть и не так много кому, но нужная. На самом деле дофига людей в бизнесе ждут такого рода нехитрые, казалось бы, специализированные микросервисы. Просто кто-то не понимает, что есть сама возможность упростить жизнь, кто-то думает что нерентабельно, кому-то [пока] вообще пофиг.
Тут главная трудность - найти "нуждающегося". Увидеть, что у (для) кого-то существует серьёзная задача, которую ты легко решишь и предложить решение. По результату мне особенно нравится блеск в глазах заказчика: "А чё, так можно было??!". И да, за это обычно нормально платят. Ну, типа, как "создание сайта" лет 15 назад тоже было магией. А для кого-то и по сей день))
Вспомнил. Классика MVC же ж. Короче, никаких on*="" в <коде />. Html вообше не должен знать, что с ним будет происходить после того, как он придёт в браузер. Исключение - html-оболочка, которая разбирает, например, json.
Snake800#: использовать надо именно предусмотрнные html'ом обработчики.
Хотя, наверное, нет: есть даже csp-политики, запрещающие inline-js. Т.е. скрипт в современных парадигмах должен выполняться "из файла", а html оставаться html"ом. И из этого наверное надо исходить.
Согласен. Ну вобщем-то я о том же говорил. Ид, классы или другие атрибуты - не суть, главное, что есть идентификатор, на который надо навешивать событие. Моё мнение, в рамках обсуждаемого вопроса, навешивание событий on* непосредственно в коде - не лучшая стратегия. Но не уверен: возможно, это просто дело привычки и пагубного влияния фрэймворков типа jQuery, а использовать надо именно предусмотрнные html'ом обработчики.
ArbNet : может сделать не навешиванием событий, а указанием их через ondblclick и onrecord
Не. Лучше через data-, кмк. Вернее так: событие должен ловить некий css-селектор (в т.ч. через data-*). А что делать с этим элементом, сотдержится в дата-атрибутах. Я так делаю. Правда я в js далеко не гуру и, возможно, вообще правильнее dom- элементы заворачивать в какую-то js-обёртку.
Если будет возможность хотя бы просто повариться в их котле, хоть на пол шишечки - обязательно стоит. Дядьки серьезные и планы у них - нагнуть Мир ;)
Да фиг знает. Яндекс тоже относительно серьёзный, а идут туда в-основном из-за строчки в резюме.
1700
Значит не из-за блоксайза.
Сейчас у меня замена меток происходит через функцию модуля работы с элементами. Но вот думается может эти функции внедрить в модуль юнита, чтобы через функцию юнита модифицировать макет и запускать открытие диалога и тд
Не видя проект сложно понять о чём речь, но могу подсказать из чего исходить. Не помню, как это называется в терминологии smell code - когда класс выполняет работу другого класса и обращается к его методам. В любом случае отталкиваетесь от обратного: конкретные функции должны быть у того модуля, который непосредственно работает с объектом.
Кому и для чего это надо?
Не знаю, мне кажется вещь хоть и не так много кому, но нужная. На самом деле дофига людей в бизнесе ждут такого рода нехитрые, казалось бы, специализированные микросервисы. Просто кто-то не понимает, что есть сама возможность упростить жизнь, кто-то думает что нерентабельно, кому-то [пока] вообще пофиг.
Тут главная трудность - найти "нуждающегося". Увидеть, что у (для) кого-то существует серьёзная задача, которую ты легко решишь и предложить решение. По результату мне особенно нравится блеск в глазах заказчика: "А чё, так можно было??!". И да, за это обычно нормально платят. Ну, типа, как "создание сайта" лет 15 назад тоже было магией. А для кого-то и по сей день))
использовать надо именно предусмотрнные html'ом обработчики.
Хотя, наверное, нет: есть даже csp-политики, запрещающие inline-js. Т.е. скрипт в современных парадигмах должен выполняться "из файла", а html оставаться html"ом. И из этого наверное надо исходить.
употреблять атрибуты "по назначению".
Согласен. Ну вобщем-то я о том же говорил. Ид, классы или другие атрибуты - не суть, главное, что есть идентификатор, на который надо навешивать событие. Моё мнение, в рамках обсуждаемого вопроса, навешивание событий on* непосредственно в коде - не лучшая стратегия. Но не уверен: возможно, это просто дело привычки и пагубного влияния фрэймворков типа jQuery, а использовать надо именно предусмотрнные html'ом обработчики.
может сделать не навешиванием событий, а указанием их через ondblclick и onrecord
Не. Лучше через data-, кмк. Вернее так: событие должен ловить некий css-селектор (в т.ч. через data-*). А что делать с этим элементом, сотдержится в дата-атрибутах. Я так делаю. Правда я в js далеко не гуру и, возможно, вообще правильнее dom- элементы заворачивать в какую-то js-обёртку.
Но там же кажется есть из чего выделять (заначку в 300 оставили)
Это даже не бумага.