Это не конструктор, это функция. В данном случае this - ссылка на контекст ее вызова.
Исходя из сказанного, в прототип функции точно писать ничего не нужно.
Olek1, я даже не заморачивался этим вопросом. У меня прозрачное меню + карта сайта.
Но, при необходимости, можно и яндоксовский поиск интегрировать, хотя лично я ни разу не пользовался внутренним поиском на других сайтах.
А я поддержу, поскольку сам vscode юзаю. А он, собственно, с атома и снят. Но саблайм не особо отличается для меня. Даже есть плюс - при выделении слова на скроллбаре показывает его расположения.
Olek1, тут нет канонических правил, есть только собственный опыт.
Мне удобнее хранить материалы в разных файлах. При этом я выигрываю:
1. При формировании страницы я подключаю файл с контентом, а не произвожу парсинг какого-то большого файла с общей базой.
2. Мне легко найти нужный файл для редактирования
3. При использовании аякса запрос идет к роутеру, возвращающему нужный контент без промежуточных серверных действий.
И это только навскидку.
Хотя есть и сторонники базового хранения информации, даже в файлах. Но я описал, почему предпочитаю именно дифференцированную файловую структуру.
Все делается через консоль или специальные аддоны для броузера.
Через консоль нужно посмотреть, как нужный элемент выглядит в html-разметке, чтобы обратиться именно к нему.
Примерно это должно выглядеть так: document.querySelector('#block_id').click();
узнать, когда и где летит объект сверху сайта и нажать на него
Нужно эмулировать клик на объекте? Тогда его координаты вовсе не нужны, достаточно обратиться к нему из скрипта, как к элементу DOM. Например, по идентификатору.
Olek1, в этом случае нужно сохранять в структуру, подобную таблице БД, после чего сериализировать в файл. Подобный метод используется в Linkor CMS, но я им не пользуюсь, поскольку тогда теряются многие преимущества использования сайта на файлах.
Lander, ну и чудненько. А то я уже подумывать стал над оптимизацией кода.
Надо будет почитать об этом вопросе подробнее, говорю же - никогда им не заморачивался.
mereci, я, к примеру, наоборот, использую такие подключения в htm-файлах для передачи каких-то переменных или результатов выполнения функций в страницу. А вот в php, при необходимости, использую echo.
Griboks, в тегах Квери указан не был. В тексте вопроса я его тоже не вижу.
Насчет использования фреймворков - в инете куча холивара, и все равно все расходятся при своем. Моё мнение - использовать их только тогда, когда тебе нужно более 50% их функционала. ИМХО, тогда это вполне себе оправдано.
зачем и когда сайту становится необходима БД? а то непонятьненько
Такой необходимости нет никогда. А вот удобство и оправданность использования, как правило, - в больших интернет-магазинах и РИА, сайтах, блогах, где количество уникальных материалов переваливает за 10 000, скажем. Цифра примерная.
Также они оправданы при высокой посещаемости сайта, поскольку лучше держат нагрузку.
Но если сайт меньше 1000 страниц и 1000 уников в сутки - ну не нужны они технически, это уж точно.
Олег Корнилов, Конечно, терпеть не могу воровство, но в такой ситуации достаточно сменить имена классов и изображений, чтобы шаблон уже не считался полной копией.
Также целиком поддерживаю мнения, что:
1. Статичный сайт намного быстрее и устойчивее динамического, однако с ним свои заморочки. Впрочем, ничто не мешает сделать комбинированный. Кстати, тот же Битрикс хранит сайт как отдельные статичные страницы, о чем можно посмотреть в его документации.
2. Сайту совершенно не нужна БД, чтобы считаться сайтом. У меня, собственно, они тоже не используются. Если сайт не большой, то они скорее вредят ему, ежели помогают. Видел сайты-визитки на Мускуле, ИМХО, полный бред.
Исходя из сказанного, в прототип функции точно писать ничего не нужно.