как заставить скрипт работать
Запуск скрипта после загрузки страницы (DOM)
Есть скрипт, который должен запуститься после загрузки DOM, так как в нём есть обращение к DOM:
Как мне запустить данный скрипт, чтобы обращение скрипта к DOM сработало?
2 ответа 2
Для тех, кто не знает, почему не работают скрипты с обращением к элементам вида :
Скрипт пытается взаимодействовать с HTML-элементами на странице, которые находятся ниже по коду, чем сам скрипт. Соответственно, скрипт уже подгрузился, а элемент, с которым нужно будет взаимодействовать, еще нет. По этой причине ничего работать не будет.
Особенность языка Javascript в том, что его код выполняется последовательно, строка за строкой, как они написаны в исходном коде.
Варианты решения данного вопроса:
Один из простых способов ― перенести в body после всех элементов. При таком расположении сначала загрузится DOM, а потом скрипт. Пример:
Но у этого метода есть недостаток: если на странице сайта куча картинок, которые грузятся пол часа, то скрипт выполнится только после того, как загрузятся все картинки и это может занят много времени.
Ещё одним минусом является то, что нельзя указывать несколько функций таким образом. Т.е. если вы два раза использовали window.onload в коде, то вторая функция сотрёт первую. Но, чтобы это исправить, я сочинил интересный костыль:
Интересный вариант ― что-то между первым и вторым пунктом. Создать особую функцию и вызывать её через скрипт в конце body. Пример:
Поддержка этого метода начинается с IE9+
Ну и подошли варианты с библиотеками. И первая наша библиотека JQuery ScriptJava. Пример:
Самый действенный вариант ― самописная функция со enStackOverflow. Работает в IE8:
var ready = (function()<
> // The DOM ready check for Internet Explorer function doScrollCheck()
И наконец самый странный и не всегда рабочий вариант ― использовать setTimeout. Пример:
Это все варианты, которые я встречал, но возможно не единственный, так как другие программисты могли придумать свои функции для решения данной задачи.
Как заставить работать скрипт на скрытых блоках? [закрыт]
Хотите улучшить этот вопрос? Обновите вопрос так, чтобы он вписывался в тематику Stack Overflow на русском.
Как я уже говорил, на тесте все работает.
На сайте структура блоков добавляется автоматически со стороны CMS движка, когда в шаблоне вывожу textarea тегом, что в итоге, посмотрев в консоле браузера, я вижу целую разметку. В этой разметке находиться блок с классом .fr-element, который и проверяется заполнен или пуст, чтобы выполнить действие и удалить класс у родителя, как мы видим в примере.
Либо скрипт загружается первым чем древо блоков, что в итоге не срабатывает, либо что-то другое.
Скрипт не хочет работать с этой цепочкой блоков, которая сформирована самим движком. Если прописать те же блоки в шаблоне, и выводить самостоятельно для теста, все прекрасно работает, пример с теми же классами выше.
Как можно решить? Прошу помощи!
Сама разметка после преобразования документа:
Исходный код сформированный при вставке в шаблон работает, класс удаляет и добавляет. Не могу понять почему, если не добавлять в шаблон сформированный код, и выводить тегом textarea, то не работает. При выводе тегом текстовое поле, движок автоматом скрывает его на странице и формирует ввод текста через div contenteditable, что в итоге получаем громоздкий код со всем на свете.
Проблема была решена, я забыл сам скрипт вставить в основной документ, что в итоге он и не срабатывал. Всем спасибо за помощь!
Фоновое выполнение скрипта на PHP без crontab
Озадачили меня тут написать демона на PHP. Т.е. скрипт, который будет заданное количество раз в заданное количество часов в случайное время (всегда случайное) выполнять определенные действия, и все это без использования cron’a.
До этого никогда не заморачивался, а тут после постановки задачи, начал было думать что так нельзя, что php скрипт надо вызывать браузером…ну задача то поставлена, надо выполнять.
Первая мысль — отключить ограничение времени выполнения скрипта. Запрещено хостером.
Вторая мысль — яваскриптом повторять аякс-запрос периодически (да хоть раз в секунду). — нельзя (требование заказчика).
Выяснилось, собственно, что и браузер открыт не должен быть, и крон нельзя использовать, и работать скрипт должен независимо от пользователя, бесконечно долго. Естественно, он должен минимум грузить систему.
1. Пачка сигарет, ночь, гугл, доки, книги, мануалы….
goto 1…
На выходе получаю:
Задача_1:
Реализовать генератор времен выполнения скрипта, исходя из заданных количества раз и количества часов. Хранить где-то эти времена.
Задача_2:
Работать после закрытия браузера
Задача_3:
Не вылетать после окончания ограничения времени выполнения скрипта
Задача_4:
Выполнять в нужное время какие-то действия.
Итак…
Пишем в конфиге исходные данные:
Далее пишем функцию, которая поможет нам сгенерировать времена запуска.
В ней мы генерируем случайное число от 0 до количества секунд в исходном интервале.
Далее сгенерируем и запишем в сессию массив времен запуска. Предварительно отсортируем массив по возрастанию, чтобы сначала шло раннее время (машину времени я еще не успел создать).
Теперь надо заставить скрипт работать, не обращая внимания на максимальное время выполнения, установленное сервером.
Принцип таков:
1) Определяем время начала работы скрипта;
2) Определяем установленное ограничение на время выполнения.
3) Запускаем цикл, внутри которого считаем текущее время и вычисляем общее время работы скрипта, сверяем текущее время со значениями в массиве времен запуска, и если совпадение есть, выполняем заданные действия (у меня они в файле exec.php). Для запуска файлов используем сокеты.
4) Повторяем цикл пока время работы скрипта не приблизится к максимально разрешенному. Я поставил — пока до максимального времени не останется 5 секунд.
Итак… считаем начальные данные по времени:
Собственно, цикл. Комментарии в коде.
Ну и, если разрешенное время подходит к концу, то завершаем цикл и благополучно запускаем этот же скрипт другие процессом (в 5 секунд точно уложимся)
Собственно, готово.
Далее у меня много заморочек было в выполнении тех самых действий — там надо было робота написать для поиска ссылок по заданным ссылкам.
Когда дописал все, озадачился полезным применением…Использовать его можно как службу. Он может следить за чем-то в сети и уведомлять Вас, например, по почте. И не надо никаких cron’ов.
Скрипт можно еще оптимизировать — доработкой не занимался.
Кстати, вот от чего я не смог оторваться — браузер все же придется открыть, чтобы изначально запустить скрипт.
Как заставить работать сторонний JavaScript на странице блога WordPress?
Здравствуйте, уважаемые блоговоды! В сегодняшнем посте я хочу поделиться с Вами небольшой фишкой, которую активно использовал в некоторых уроках, а именно «заставлял» работать javascript-коды, а также некоторые коды css.
Особенно актуальной информация будет для тех, кто ведет блог о создании сайтов, используя в них примеры различных скриптов. Подойдет не только для WordPress, но и для других систем управления контентом.
Существует вариант вывода javascript, да и любого кода с помощью произвольных полей, однако таким способом отобразить скрипт в работе можно будет только в шаблоне блога, изменив php-код его файлов. Нам же нужно, чтобы скрипт работал прямо на странице/в записи блога.
Также я находил пример использования JavaScript в записях блога в кодексе WordPress (на английском), однако и такой вариант меня тоже не устроил.
JavaScript WordPress
Первый и самый простой способ — вынести скрипт на отдельную html-страницу и поставить на нее ссылку вида «Демо».
При создании самой страницы не забываем указывать кодировку UTF-8 (без BOM), потому что если на странице есть русские буквы, они будут отображаться кракозябрами!
Способ второй — использование фреймов (iframe).
Точно также создаем html-страницу, запихиваем в нее скрипт-код, а на странице/в записи блога добавляем iframe.
Код iframe:
Ничего сложного нет! Просто указываете ширину и высоту фрейма и отключаете полосу прокрутки с помощью scrolling=»no».
Приведу несколько примеров iframe, которые использованы в некоторых записях моего блога:
Идем далее. Теперь разберемся с тем, как продемонстрировать сторонние css-стили, которых нет в файле style.css шаблона блога.
Такой прием я использовал тогда, когда прописывание стилей непосредственно в самом html-коде не давало никаких результатов.
В таком случае я создавал отдельный файл *.css, где прописывал все стили, а на странице поста использовал код подключения (импорта) в режиме html:
Еще один вариант — прописывание стилей прямо в тексте поста (тоже в режиме html), например вот так:
Но первый вариант мне больше нравится, поскольку все стили прописаны в стороннем файле, и не нужно засорять пост дополнительными стилями.
Примеры работы данного метода:
Вот такими вот хитростями мне приходится иногда пользоваться при демонстрации работы скриптов и CSS в некоторых постах блога!
В любой непонятной ситуации — пиши скрипты
Скрипты — один из самых распространенных способов сделать приложение более гибким, с возможностью поправить что-то прямо на ходу. Конечно же, у этого подхода есть и недостатки, нужно всегда помнить про баланс между гибкостью и управляемостью. Но в этой статье мы не будем рассуждать “в общем” по поводу плюсов и минусов использования скриптов, мы рассмотрим практические способы реализации этого подхода, а также представим библиотеку, которая предоставляет удобную инфраструктуру для добавления скриптов в приложения, написанные на Spring Framework.
Несколько вводных слов
Когда хочется добавить возможность менять бизнес-логику в приложении без перекомпиляции и последующего развертывания, то скрипты — один из способов, который приходит на ум в первую очередь. Зачастую, скрипты появляются не потому что так было задумано, а потому что так получилось. Например, в спецификации есть часть логики, которая вот прямо сейчас не до конца ясна, но, чтобы не тратить лишние пару дней (а иногда и дольше) на анализ, можно сделать точку расширения и вызывать скрипт — заглушку. А потом, конечно, этот скрипт будет переписан, когда требования прояснятся.
Способ не новый, и его достоинства и недостатки хорошо известны: гибкость — можно поменять логику на работающем приложении и сэкономить время на редеплое, но, с другой стороны, скрипты сложнее тестировать, отсюда — возможные проблемы с безопасностью, производительностью и т.д.
Те приемы, которые будут рассмотрены далее, могут быть полезны как разработчикам, которые уже используют скрипты в своем приложении, так и тем, кто только думает об этом.
Ничего личного, только скриптинг
С JSR-233 скриптинг в Java стал очень простым. Существует достаточное количество скриптовых движков, основанных на этом API (Nashorn, JRuby, Jython и ещё некоторые), так что добавить немного скриптовой магии в код — не проблема:
Очевидно, что, если такой код будет раскидан по всему приложению, то оно превратится непонятно во что. И, безусловно, если у вас в приложении больше одного вызова скрипта, то нужно делать отдельный класс для работы с ними. Иногда можно пойти ещё дальше и сделать специальные классы, которые будут оборачивать вызовы evaluateGroovy() в обычные типизированные Java методы. В этих методах будет довольно однотипный служебный код, как в примере:
Такой подход сильно увеличивает прозрачность при вызовах скриптов из кода приложения — сразу видно, какие параметры скрипт принимает, какого они типа и что возвращается. Главное — не забыть добавить в стандарты написания кода запрет на вызов скриптов не из типизированных методов!
Прокачиваем скрипты
Несмотря на то, что скрипты — это просто, если у вас их много и вы их интенсивно используете, то есть реальный шанс столкнуться с проблемами производительности. Например, если используется куча groovy шаблонов для генерации отчетов и вы их запускаете в одно и то же время, рано или поздно это станет одним из узких мест в производительности приложения.
Поэтому многие фреймворки делают разнообразные надстройки над стандартным API для улучшения скорости работы, кэширования, мониторинга выполнения, использования разных скриптовых языков в одном приложении и т.д.
Например, в CUBA был сделан довольно хитроумный движок для скриптинга, который поддерживает дополнительные возможности, такие как:
И было бы несправедливо не упомянуть GraalVM — экспериментальный движок, который умеет выполнять программы на разных языках (JVM и не-JVM) и позволяет вставлять в Java приложения модули на этих языках. Я надеюсь, что Nashorn рано или поздно уйдет в историю, и у нас будет возможность писать части кода на разных языках в одном исходнике. Но это пока только мечты.
Spring Framework: предложение, от которого сложно отказаться?
В Spring есть встроенная поддержка исполнения скриптов, построенная на базе API JDK. В пакете org.springframework.scripting.* можно найти много полезных классов — все, чтобы можно было удобно использовать низкоуровневый API для скриптинга в своем приложении.
Кроме этого, есть более высокоуровневая поддержка, она подробно описана в документации. Вкратце — нужно сделать класс на скриптовом языке (например, Groovy) и опубликовать его как бин через XML описание:
После того, как бин опубликован, его можно добавлять в свои классы при помощи IoC. Spring обеспечивает автоматическое обновление скрипта при изменении текста в файле, можно вешать аспекты на методы и т.д.
Выглядит неплохо, но нужно делать “настоящие” классы для того, чтобы их опубликовать, обычную функцию в скрипте не напишешь. Кроме того, скрипты можно хранить только в файловой системе, для использования БД придется лезть внутрь Spring. Да и XML конфигурацию многие считают устаревшей, особенно если в приложении уже все на аннотациях. Это, конечно, вкусовщина, но с ней зачастую приходится считаться.
Скрипты: трудности и идеи
Итак, у каждого решения есть своя цена, и, если говорить о скриптах в Java приложениях, то при внедрении этой технологии можно столкнуться с некоторыми трудностями:
Вдобавок ко всему, если каждый скрипт будет связан только с одним методом, можно быстро найти все точки вызова в приложении при помощи меню “Find Usages” из IDE и понять место скрипта в каждом конкретном алгоритме бизнес-логики.
Упрощается тестирование — оно превращается в “обычное” тестирование классов, с использованием привычных фреймворков, mock’ами и прочим.
Все вышеописанное очень созвучно с идеей, упомянутой в начале статьи — “специальные” классы для методов, которые реализуются скриптами. А что, если сделать ещё один шаг и скрыть весь служебный однотипный код для вызовов скриптовых движков от разработчика, чтобы он про это даже не думал (ну, почти)?
Репозитории скриптов — концепт
Задумка довольно проста и должна быть знакома тем, кто хоть раз работал со Spring, особенно со Spring JPA. Что нужно — сделать Java интерфейс и при вызове его методов вызывать скрипт. В JPA, кстати, используется идентичный подход — вызов CrudRepository перехватывается, на основе имени метода и параметров создается запрос, который потом выполняется движком БД.
Что нужно, чтобы реализовать концепт?
Для начала — аннотация уровня класса, чтобы можно было найти интерфейс — репозиторий и сделать бин на его основе.
Также, наверное, пригодятся аннотации на методы этого интерфейса для того, чтобы хранить метаданные, нужные для вызова метода. Например — откуда брать текст скрипта и какой движок использовать.
Полезным дополнением будет возможность использовать методы с реализацией в интерфейсе (a.k.a. default) — этот код будет работать, пока бизнес-аналитик не выведает более полную версию алгоритма, а разработчик не сделает скрипт на основе
этой информации. Или пусть аналитик скрипт пишет, а разработчик потом просто скопирует его на сервер. Вариантов много 🙂
Итак, предположим, что для интернет-магазина нужно сделать сервис для вычисления скидок на основе профиля пользователя. Прямо сейчас непонятно, как это делать, но бизнес-аналитик клянется, что всем зарегистрированным пользователям полагается скидка 10%, остальное он выяснит в течение недели у заказчика. Сервис нужен прямо завтра — сезон все-таки. Как может выглядеть код для такого случая?
А потом подоспеет и сам алгоритм, написанный, например, на groovy, там скидки будут немного отличаться:
Вызов читаемый, понятный, и, чтобы его сделать, не надо обладать никакими особыми навыками.
Это были идеи, на основе которых была сделана небольшая библиотека для работы со скриптами. Она предназначена для Spring приложений, этот фреймворк использовался для создания библиотеки. В ней предоставляется расширяемый API для загрузки скриптов из различных источников и их выполнения, который скрывает рутинную работу со скриптовыми движками.
Как это работает
Общее устройство библиотеки показано на диаграмме. Синим выделены компоненты, которые нужно разработать, белым — которые уже есть в библиотеке. Значком Spring помечены компоненты, которые доступны в контексте Spring.
Когда вызывается метод интерфейса (по факту — прокси-объекта), запускается обработчик вызова, который в контексте приложения ищет два бина: провайдера, который будет искать текст скрипта, и исполнителя, который, собственно, найденный текст будет выполнять. Потом обработчик возвращает результат вызвавшему методу.
Можно заметить аннотации @ScriptParam — они нужны для того, чтобы указывать имена параметров при передаче их в скрипт, поскольку Java компилятор стирает исходные имена из исходников (есть способы заставить его это не делать, но лучше на это не полагаться). Можно имена параметров и не указывать, но, в таком случае, в скрипте нужно будет использовать “arg0”, “arg1”, что не сильно улучшает читаемость.
Тестирование и версионирование
Поскольку скрипты меняются часто и легко, нужно иметь способ как-то убедиться, что изменения ничего не ломают. Библиотека совместима с JUnit, репозиторий просто можно протестировать как обычный класс в составе юнит или интеграционного теста. Mock библиотеки тоже поддерживаются, в тестах к библиотеке можно найти пример того, как сделать mock на метод репозитория скриптов.
Если нужно версионирование, то можно создать провайдера, который будет читать разные версии скриптов из файловой системы, из базы данных или из Git, например. Так можно будет легко организовать откат на предыдущую версию скрипта в случае неполадок на основном сервере.
Итого
Представленная библиотека поможет организовать скрипты в Spring приложении: