Snake800

Snake800
Рейтинг
237
Регистрация
02.02.2011
(_._)
Александр #:

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

Да фиг знает. Яндекс тоже относительно серьёзный, а идут туда в-основном из-за строчки в резюме.

Файлов много? Может связано с размером физического блока на доске?
ArbNet #:
Сейчас у меня замена меток происходит через функцию модуля работы с элементами. Но вот думается может эти функции внедрить в модуль юнита, чтобы через функцию юнита модифицировать макет и запускать открытие диалога и тд

Не видя проект сложно понять о чём речь, но могу подсказать из чего исходить. Не помню, как это называется в терминологии smell code - когда класс выполняет работу другого класса и обращается к его методам. В любом случае отталкиваетесь от обратного: конкретные функции должны быть у того модуля, который непосредственно работает с объектом.

ArbNet #:
Кому и для чего это надо?

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

Тут главная трудность - найти "нуждающегося". Увидеть, что у (для) кого-то существует серьёзная задача, которую ты легко решишь и предложить решение. По результату мне особенно нравится блеск в глазах заказчика: "А чё, так можно было??!". И да, за это обычно нормально платят. Ну, типа, как "создание сайта" лет 15 назад тоже было магией. А для кого-то и по сей день))

Вспомнил. Классика MVC же ж. Короче, никаких on*="" в <коде />. Html вообше не должен знать, что с ним будет происходить после того, как он придёт в браузер. Исключение - html-оболочка, которая разбирает, например, json.
Snake800 #:
использовать надо именно предусмотрнные html'ом обработчики.

Хотя, наверное, нет: есть даже csp-политики, запрещающие inline-js. Т.е. скрипт в современных парадигмах должен выполняться "из файла", а html оставаться html"ом. И из этого наверное надо исходить.

webinfo #:
употреблять атрибуты "по назначению".

Согласен. Ну вобщем-то я о том же говорил. Ид, классы или другие атрибуты - не суть, главное, что есть идентификатор, на который надо навешивать событие. Моё мнение, в рамках обсуждаемого вопроса, навешивание событий on* непосредственно в коде - не лучшая стратегия. Но не уверен: возможно, это просто дело привычки и пагубного влияния фрэймворков типа jQuery, а использовать надо именно предусмотрнные html'ом обработчики.

ArbNet :
может сделать не навешиванием событий, а указанием их через ondblclick и onrecord

Не. Лучше через data-, кмк. Вернее так: событие должен ловить некий css-селектор (в т.ч. через data-*). А что делать с этим элементом, сотдержится в дата-атрибутах. Я так делаю. Правда я в js далеко не гуру и, возможно, вообще правильнее dom- элементы заворачивать в какую-то js-обёртку.

vitaliy11 #:
Но там же кажется есть из чего выделять (заначку в 300 оставили)

Это даже не бумага.

Всего: 2062