Блог о Frontend-разработке, ботоводстве, iMacros + Javascript

Исследование различных веб-технологий, математических алгоритмов и проектирование веб-приложений.

Рубрики

Комменты

• Сергей к записи [Урок 11] . Формат JSON, как хранилище любых данных в iMacros.
• Сергей к записи [Урок 11] . Формат JSON, как хранилище любых данных в iMacros.
• Тру-ля-ля к записи [Урок 9] . Чтение и запись txt-файлов в iMacros. Разбираем говнокод и смотрим «Best Practice».
• Mirex к записи [Урок 14] . 100%-распознавание капчи reCaptcha v.2 в iMacros+JS через сервис rucaptcha.com
• Никита к записи Как отключить Safe Mode(Безопасный режим) в Firefox

[Урок 3] . Получение любой информации со страницы при помощи Javascript

Каждый уважающий себя бот должен уметь извлекать любую информацию с сайта, например ссылки, заголовки, любой текст, номера телефонов, адреса электронной почты, картинки. В этом уроке мы рассмотрим несколько методов сбора данных на странице при помощи iMacros и Javascript.

Исходный код страницы

Для начала, я хочу очень кратко рассказать про то, из чего состоит веб-страница. Вы можете открыть любой сайт, например мой блог и нажать Ctrl+U (или правой кнопкой на странице и выбрать «Исходный код»). Вы увидите код, это обычный текст в формате HTML, который браузер преобразует в веб-страницу. Ключевые слова, заключенные в «<>» — называются тегами, свойства внутри них — атрибутами и значениями атрибута. Все это нам пригодится, чтобы отыскивать необходимые теги с нужной информацией.

Пример:

Что же делает браузер с этим кодом? Браузер, руководствуясь этим кодом, располагает информацию на странице в указанном порядке, подгружает таблицы стилей css, которые добавляют оформление элементам, подгружает и вставляет картинки, скачивает и выполняет различные скрипты. Правила, по которым браузер это делает — называются спецификацией, которая необходима, чтобы все браузеры отрисовывали страницы и обрабатывали скрипты одинаково.

DOM (Document Object Model) – объектная модель страницы

Основным инструментом работы и динамических изменений на странице является DOM (Document Object Model) – объектная модель, используемая для XML/HTML-документов. Согласно DOM-модели, документ является иерархией, деревом. Каждый HTML-тег образует узел дерева с типом «элемент». Вложенные в него теги становятся дочерними узлами. Для представления текста создаются узлы с типом «текст».

DOM – это представление страницы в виде дерева объектов, доступное для чтения и изменения через JavaScript.

При чтении неверного HTML браузер автоматически корректирует его для показа и при построении DOM. В частности, всегда будет верхний тег . Даже если в тексте нет – в DOM он будет, браузер создаст его самостоятельно. То же самое касается и тега . Например, если файл состоит из одного слова «Test» , то браузер автоматически обернёт его в и .

При генерации DOM браузер самостоятельно обрабатывает ошибки в документе, закрывает теги и делает все, чтобы корректно отобразить документ.

Методы извлечения информации из тегов средствами iMacros

У iMacros есть возможности для извлечения текста и даже html-кода из тегов. Для начала я рекомендую вам установить расширение FireBug, если вы этого еще не сделали. Открывается он по нажатию клавиши F12, либо вы можете нажать в любом месте страницы правой кнопкой и тыкнуть «Инспектировать элемент при помощи Firebug».

Чтобы потренироваться и как следует разобраться, я создал для вас специальную страничку
http://polygon.nagibaka.ru/lessons/lesson3/index.htm

Давайте приступим, я рекомендую вам сразу открыть эту ссылку в Firefox. Поскольку вам предстоит писать много кода, рекомендую первым делом поставить себе какой-нибудь редактор, например весьма распространенный Notepad++ или же мой любимый и в сто раз более удобный Sublime Text 3, я писал о плагинах для него и режиме Vim для быстрого и мощного редактирования.

Давайте нажмем на «Запись» в iMacros, тыкнем по первому заголовку и остановим запись.

Мы получим вот такой скрипт(Current.iim):

Давайте переделаем его в JS.
Создайте новый файл, например test.js. Допустим, нам необходимо получить содержимое тега «

» . Переделаем макрос на js и извлечем из него содержимое тега «

Результат(test.js):

Обратите внимание — я заменил «Тестовая страница» на «*» — поскольку текст заголовка может быть любым, а звездочка нам говорит, что текст может быть произвольным
TYPE=H1 — указывает что мы ищем тег «

«, можно указать любой другой
POS=1 — указывает, что мы выбираем первый попавшийся тег

, ведь на странице их может оказаться несколько
ATTR=TXT:* — указывает значение атрибута, в данном случае служебный атрибут, который ищет совпадение в тексте внутри тега
EXTRACT=TXT — указывает, что мы извлекаем текст, также можно указать «EXTRACT=HTM» , чтобы извлечь текст вместе со всеми тегами

Методы извлечения информации из тегов средствами Javascript

Теперь давайте перепишем код полностью на JS без использования iim-команд. Еще, вместо iimDisplay мы будем использовать window.console.log(‘any text and vars’); Данные, которые мы будем выводить этой командой — будут отображаться в консоли firebug. Такой вариант удобнее по многим причинам, например, можно выводить js-объекты и удобно просматривать их содержимое. А самое главное, при помощи iimDisplay единовременно можно смотреть только последнее выведенное сообщение, а c этой командой мы увидим полный лог. Небольшое примечание, в некоторых старых версиях FF(например 27), window.console.log не всегда работало, и обратите внимание, нужно писать именно window.console.log , несмотря на то, что при создании обычных сайтов, чаще пишут просто console.log , весь наш код выполняется в контексте расширения iMacros, поэтому необходимо добавлять window .

Код на JS(test.js):

Здесь мы использовали поиск элемента по тегу. На самом деле, метод querySelector принимает в качестве параметра любое выражение в формате css-правила. Еще важно знать, что querySelector возвращает только первый элемент из DOM-дерева, который совпал. Чтобы получить все элементы, подходящие под указанное правило, используйте querySelectorAll .

Источник

Как вывести информационное сообщение автора на страничках блога — php html

Выводить нужную информацию в качестве сообщений администратора сайта, а в том числе «приветствие» или всевозможные «подписки», можно различными способами (например, как описано ЗДЕСЬ) — но —

…иногда у админа возникают какие-то свои требования, а, следовательно, и решения должны быть соответствующими.

Вот их сегодня и рассмотрим:

Конечно, возможно инфу вписать непосредственно в определённый HTML документ, соорудив кодик и поместив его в файл single.php или post-single.php и т.п. А возможно прямо в тело статьи, использовав теги шорткода, а возможно… !!

О всех плюсах и минусах этих предприятий написано вот тут — правильное использование кода …

Главнейшим минусом правки нескольких HTML документов — является — правка нескольких документов )) — при смене характера информационного сообщения возникает необходимость править код во всех включенных документах… А это неудобно!!

Посему сегодня поступим немного иначе: рассмотрим в качестве примера «приветствие автора», форму которого можно будет при необходимости заменить подправив один только файл, а именно файл functions.php … Хотя, как понимаете, вариации сообщений могут быть какими угодно и если вы выводите какие-то совершенно разные информационные сообщения, к примеру, рекламные строки в разделах категорий, меток, отдельных записей, страничках и т.п. всегда выручит PHP…

как вывести сообщение в блоге посредством файла functions.php

Воспользуемся вот этой достаточно известной функцией (я её только фамильным гербом обозначил: а вообще имя может быть любое):

Вот такой незамысловатый кодик нам нужно прописать в наш легендарный файл функций functions.php — перед закрывающим тегом ?> .

Одно дело сделано!

А о том как выводить сообщение-информацию администратора (автора) блога непосредственно на «ЛИЦО» сайта рассмотрим ниже, а пока разберём некоторые нюансы:

Общеизвестно, что характер информационной фразы т. е. её написание — разнообразно !! — информационная фраза может быть, например, закавычена внутри… (т.е проставлена какая-то символика, которая используется и в программировании) и коли такую многосимволичную фразу поместить в php файл — будет ошибка !! ибо символика же несёт определённую нагрузку в системном чтении документа.

Так как же поместить кавычки внутри других кавычек в коде php.

…и заставить правильно отрабатывать документ…

…проблему можно решить такими способами:

первый: используйте одинарные кавычки внутри двойных или наоборот…

И ещё один вариант — это экранирование проблемной символики с помощью обратной косой черты ( бэкслеш — backslash) \ . Так называемое экранирование задаёт отмену кавыч-функции, которую обозначал символ — и превращает его в обычный.

Обозначенная экраном кавычка будет выведена на экран (браузера) как обычная, ибо теперь не несет никакой функциональной состовляющей.

В программировании нельзя забывать об ЭКРАНЕ каким бы тот экран ни был), посему необходимо умение им пользоваться.

То есть — вот код самой функции, которая (или который) и выводит сообщение на страничку сайта, стоит только разместить этот примерчик в нужном месте документа:

Как понимаете, код вывода функции правильнее завернуть в id-класс, чтобы предложение имело соответственно характерную стилистику…

…Ну — к примеру, путь id будет таким:

А вот и примерные стили нашего чуда:

Свойства и значения CSS возможно менять соответственно вашей фантазии…

На этой высокой ноте завершу сегодняшнее повествование, ибо всё. рассказал.

В следующих статьях научимся выводить более сложные комбинирования кода HTML и PHP!

вероятно, имеет смысл подписаться:

Online консультация по настройкам и созданию сайтов на WordPress

В качестве бонуса: только нужно непременно прочесть этот пост …ибо я расскажу кратко.

Можно к примеру добавить кнопочку в HTML редактор вордпресс «завершение» или, мол, «поделитесь в соцсетях» чтобы не писать однообразный текст сотни раз!

Например, такие экзерсисы… ))

Естественно, всю стилистику фраз (в коде) можно поубирать напрочь, а уж подстраивать всяческую гармонию буков непосредственно в статье…

Но — для реализации этих примочек напоминаю: прочтите пост — ссылка выше…

Связка Contact Form 7 с плагином CF7 Google Sheet Connecto (отправим данные из формы связи в таблицы Google)

Михаил ATs — владелец блога запросто с Вордпресс — в сети нтернет давным-давно.

. веб разработчик студии ATs media: помогу в создании, раскрутке, развитии и целенаправленном сопровождении твоего ресурса в сети. — заказы, вопросы. разработка.

Источник

PHP. Вывод окна сообщения

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

PHP — выполнение скрипта и вывод сообщения в HTML
Доброго времени суток!Обращаюсь к вам ,о Великие гуру PHP 🙂 Существует 25 этапов ,которые.

Не выводить сообщения на PHP, Index.php файл!
Здравствуйте! Файл index.php, есть head block и меню. Потом в body я хочу прописать php скрипт.

Php!? при закрытии окна выполнить файл del.php!?
Как отловить закрытие окна, при его закрытии должен выполниться некий файл del.php!?

PHP обработка сообщения
Добрый вечер. Народ, очень прошу помощь новичку в написании обработчика для отправки сообщений.

Зачем вывод для регистрации делать на js?

Страица всеравно будет перезагружаться. И результат можно вывести на php.

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

Решение

Отправка сообщения в php
Правильно я понял что бы отправить сообщение на почту надо вызвать функцию mail() ? но я не могу.

Личные сообщения php
Всем привет. Заметил на одном сайте такую интересную вещь: скажем я зарегистрировался на сайте и.

PHP отправка сообщения на почту
Кто силен в PHP помогите с кодом отправки на почту текста из html форм.. вот у меня есть готовый.

Вывод сообщения
Приветствую всех ! Необходимо сделать вывод сообщения после отправки формы (на почту) ! После.

Источник

Вывод сообщений пользователю в веб-приложениях.

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

Очень часто создание и вывод сообщений разнесены по разным HTTP-запросам. Как правило, удобно бывает использовать редирект после обработки форм (чтобы избежать проблем с кнопками Back и Refresh), но в то же время естественный момент для создания сообщения — это именно момент обработки форм и совершения действий, ему сопутствующих. Почему? Представьте, что текст сообщения должен выглядеть примерно так: «Количество заказываемых единиц товара ‘Коврик для мыши’ успешно изменено с 7 до 12». После редиректа, возможно, на совершенно другую с точки зрения функциональности страницу, это будет лишняя головная — определить, что же было совершено до этого.

Чаще всего сообщения выводят именно в POST-запросе, который занимается обработкой формы — это нехорошо, надписи «эта страница устарела» портят жизнь (когда пользователю вздумается попробовать кнопку Back).

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

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

Итак, имеем проблему — сообщение должно «жить» в разных запросах. Нам нужен механизм передачи текста сообщения на страницу, которая должна его выводить. Вы уже, наверное, вспомнили про сессии.

Да, вобщем-то вы правы. Прочие способы, например через глобальную переменную, не позволяют сохранить данные в случае, когда используется редирект (замечание Максима Науменко). Плюс еще я обычно делаю так, чтобы каждый экран в приложении имел возможность, наряду с прочей информацией, выводить сообщения, которые были сформированы на предыдущих экранах. Это удобно, потому что не потребуется готовить отдельные экраны для вывода сообщений, а пользователю не придется лишний раз щелкать мышью. Но, правда, здесь надо подумать дизайнеру — выделить область, в которой бы появлялись сообщения.

Идея очень простая, и ее можно реализовать с помощью пары классов.

Первое, что приходит в голову — создать класс Message, который бы, собственно, и представлял собой сообщение на нашей нехитрой схеме классов. Сообщение должно уметь сохранять себя в сессии, а также выводить себя на экран.

Для доступа к сессии используется переменная $_SESSION.

Замечу, что $_SESSION — это массив, мы используем всего лишь один элемент этого массива с индексом ‘session_message’.

В данном случае имеем дело с «массивом массивов» — то, что мы храним в элементе ‘session_message’, представляет собой массив, это и есть список передаваемых сообщений (их, конечно, может быть несколько).

Если вы не смогли нащупать нить, самое время освежить в памяти разделы мануала, посвященные сессиям и массивам.

У вас может возникнуть вопрос. А зачем здесь нужны классы? Вполне можно было бы обойтись двумя функциями. Но давайте заглянем дальше. Нам может понадобиться создавать сообщения с различными типами (info, error, warning), определять адресатов сообщений.

Заметьте, что в данный момент в сессию кладется не сам объект, а только текст сообщения. ООП позволяет нам в дальнейшем поменять поведение метода send(), не меняя клиенский код, который обращается к этому методу (например, в будущем в сессию можно записывать полностью объект Message, если в нем будет много полей).

Представим, что мы бы это делали с помощью функций. Наверное, у нас была бы функция message_send($txt), еще была бы функция message_to_page($txt). Теперь надо добавить возможность различного поведения для различных видов сообщений. Вызовы функций меняются: message_send($txt, $kind), message_to_page($txt, $kind). Придется прочесать весь код приложения в поисках таких функций, делая исправления.

Этого можно избежать, заранее предвидя ситуацию, представив сообщение в виде ассоциативного массива: $msg[‘txt’], $msg[‘kind’], тогда в вызовах функций будет только один параметр. Чувствуете, как это стремится превратиться в класс?

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

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

Следующий класс — Inbox — как раз для этого и предназначен.

Давайте испытаем нашу систему сообщений.

Создадим очень простой пример, который в ответ на отправку формы будет сообщать количество секунд в текущей минуте.

Всю работу с массивами и сессиями мы спрятали внутри классов, и конечный код выглядит просто и красиво.

Создайте каталог на веб-сервере, затем создайте в нем эти три файла и попробуйте скрипт в работе. Заметьте, проблем с кнопками Back и Refresh не возникает.

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

Здесь мы встречаем два затруднения:

* Хотелось бы, чтобы список сообщений появлялся в определенной части страницы, и вы уже подобрали хорошее местечко для этого.
Проблема в том, что надо запустить команду $inbox->toPage() именно в тот момент, который бы соответствовал положению списка сообщений на странице. Если мы захотим поменять положение этого списка, придется лезть в код, но нехорошо постоянно для этого изменять каркас портала. Наилучшим решением было бы сделать вывод сообщений в виде отдельного модуля, о котором известно лишь только, что его надо подключить к каркасу.
То есть освободиться от строгой последовательности запуска модулей. Действительно, раз результат работы вывода Inbox не зависит от работы системы (на данном шаге — все данные у нас уже есть в сессии), то зачем лишние сложности ?
* Чтобы поддерживать внешний вид (дизайн) списка сообщений надо заботиться об HTML-коде, который у нас зашит в методах toPage() классов Message и Inbox. Как правило, придется изменять PHP-код для того, чтобы изменить дизайн.

Чтобы попытаться решить первую проблему, можно создать буфер, в котором бы хранился результат работы вывода Inbox.

Возможно, у нас еще будет несколько похожих (на Inbox) вещей, и надо создать систему буферов. Для того, чтобы не перепутать где чей вывод, мы, наверное придем к именованию буферов. У нас будет где-то храниться последовательность, в соответствии с которой должен происходить вывод буферов — желательно во внешнем файле, чтобы легче было вносить изменения.

Уже эта попытка решения дает нам идею использовать XML как средство хранения промежуточных данных. А использование стилей XSLT поможет справиться и со втором проблемой.

Я не буду останавливаться на том, что такое XML, и что такое XSLT. Если вы не знакомы с этими вещами, zvon.org станет хорошей отправной точкой для изучения.

Идея в том, чтобы в методах toPage() формировать не HTML-код, а XML структуру. Документ страницы будет создаваться в виде стринга с XML-кодом (он будет служить в качестве «буфера»), а на последней стадии работы скрипта мы будем использовать XSL-трансформацию.

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

Что это такое — догадаться довольно просто — два сообщения и форма. Заметьте, PHP-скрипт должен подготовить только такой стринг — он очень простой. Причем порядок следования основных тегов неважен — можно поставить вначале, например, как будет удобно программисту. Как это реализовать. Можно, почти ничего не меняя, использовать output buffering, вместо HTML-кода выводить XML, а в конце просто захватить вывод в стринг. Но тогда мы потеряем в гибкости — например, хочется иногда выводить отладочную информацию прямо на страницу (с помощью echo). В то же время, разработчики PHP работают над DOM-модулем, который предлагает более продвинутый способ создания и передачи древовидных документов. Если мы захотим внедрить DOM, то придется перекраивать все приложение, изменяя вывод стрингов на создание DOM-элементов. Поэтому я предпочитаю хранить XML-представление объектов внутри самих объектов, последовательно собирая общий XML-документ. Это не так сложно, нужна всего лишь небольшая модификация. Вы увидите, что такой прием не привязан жестко к конкретному способу хранения XML-данных, и это позволит совершить переход к использованию DOM «малой кровью». Прежде всего заметим, что у каждого нашего объекта есть метод toPage(). Эта похожесть должна нас заставить задуматься о том, чтобы ввести новый общий родительский класс. Пусть каждый класс, который способен создавать кусочки XML-документа для страницы, будет наследоваться от класса, который будет заботиться об XML-представлении объекта. Назовем его Outputable.

Метод toPage() сделан пустым — в данном случае он нужен как индикатор того, как должны внешние «матрешки»-классы общаться с внутренним классом. Впрочем, здесь можно было бы предложить реализацию по умолчанию, если бы мы заметили, что есть много объектов, которые одинаково выводят себя на страницу.

Классы Message и Inbox несколько изменятся — теперь оба они должны наследоваться от Outputable, а также изменятся и методы toPage()
Message.php

Изменился способ вывода — теперь вместо непосредственного вывода на страницу внешнее представление до поры до времени хранится в Outputable, который «сидит» в каждом из объектов. Метод appendOutput() служит некоторой заменой конструкции echo(). Чтобы забрать вывод объекта, используется метод getOutput().

Теперь посмотрим, что собой представляет клиентская часть кода, которая будет решать ту же задачу, что и раньше.
index.php

Главное новшество — в объекте $global_content, название которого говорит само за себя. В данном случае он принадлежит классу Outputable, в реальных задачах вы, наверное, создадите отдельный класс для контента страницы.

Если внимательно присмотреться, то содержательная часть скрипта практически не изменилась — тот же inbox, тот же toPage(). Добавлена инструкция, которая содержимое списка сообщений выводит в контент страницы. Для разнообразия теперь генерируется два сообщения.

Для того, чтобы посмотреть на результат, осталось только подготовить XSL-шаблон.
style.xsl

Чего же мы добились?

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

Любой модуль, который генерирует XML-данные в качестве результата своей работы, может быть использован в проекте. Кстати, это одно из преимуществ перед template-движками, в которых создание данных заключается в последовательности вызова методов (assign и т.п.) конкретного движка, на которых нет общего стандарта.

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

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

Напоследок, галопом о перспективах:

* всплывающие окна для списка важных сообщений
* «страницы-отправители» и «страницы-адресаты» в сообщениях
* ведение лога сообщений в базе данных
* кнопка «показать историю моих действий»
* статистический анализ действий пользователей в пределах сессий
* «интеллектуальные помощники» в веб-приложениях

Источник