[xParser] 1.3.0 - Регулярные выражения + Кейс

Обработка регулярным выражением полученных данных доступна уже давно, благодаря такой сногсшибательной функциональности Fenom. А с версии 1.3.0 регулярки были внедрены:
а) в конфигурацию задания при указании записи селектора,
б) в поля источника.

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

Кейс

Дано

Возникла потребность распарсить сайт, имеющий странную структуру записей. На CSS или XPath синтаксисе к ним было не подобраться. Пример странной структуры:

<div class=content>
<p> 
<h2>Какой-то заголовок</h2>
Текст с описанием раздела
<p>
18.01.10 <a href="http://domain.zone/link1.html">Запись 1</a>
< br>Описание записи 1
<p>
24.12.09 <a href="http://domain.zone/link2.html">Запись 2</a>< br>
Описание записи 2
<p>
23.12.09 <a href="http://domain.zone/link3.html">Запись 3</a>
< br>Описание записи 3
<p>
22.12.09 <a href="http://domain.zone/link4.html">Запись 4</a>< br>
Описание записи 4
...
</div>

Я умышленно поставил пробел перед br, т.к. modx.pro съедал их.

Что мы имеем:

1. Запись не содержится в отдельном контейнере. Отсюда сложность получить ее. Решаемо за счет регулярки!
2. Теги p в каждой записи открыты, но не закрыты. Решается внутренними средствами xParser без вашего участия!
3. Тег br может стоять, как сразу после ссылки, так и на следующей строке под ней. Решаемо за счет регулярки!

Версия xParser ниже 1.3.0 не решала такое, честно скажем…

Выборка записи

Как обычно, мы создаем задание. Только теперь при указании селектора записи в конфигурации задания, мы можем выбрать синтаксис, среди которых: CSS, XPath, RegExp. Нам нужны регулярные выражения!


Вот такую регулярку я составил для выборки записей из странной структуры:

/<p>\s?([0-9]{2}\.[0-9]{2}\.[0-9]{2}) <a href="([^"]+)">(.+)<\/a>\s?< br>\s?(.*)\s?<\/p>/ui

Я умышленно поставил пробел перед br, т.к. modx.pro съедал их.

Таким образом мы получим каждую запись на странице. Всего их было около 100 шт.

Поля источника

После чего нам надо распарсить поля источника. Это я тоже реализовал на регулярных выражениях:


Ссылка:
Синтаксис: RegExp
Ключ: link
Селектор:

/<a.*href="([^"]+)/ui

Дата:
Синтаксис: RegExp
Ключ: date
Селектор:

/<p>\s?([0-9]{2}\.[0-9]{2}\.[0-9]{2})/ui

Описание:
Синтаксис: RegExp
Ключ: description
Селектор:

/<p>\s?[0-9]{2}\.[0-9]{2}\.[0-9]{2} <a href="[^"]+">.+<\/a>\s?< br>\s?(.*)\s?<\/p>/ui

Я умышленно поставил пробел перед br, т.к. modx.pro съедал их.

Итого

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

А ещё в прошлых версиях были добавлены классные функции:

1. Указание кодировки страницы-источника,
2. Переменная $_pls в параметры @INLINE чанка в системном поле, которая содержит массив значений, для получения нестандартных полей, например с двоеточием в ключе,
3. Можно указывать скачивание медиа для конкретных полей, а не для всего задания в целом,
4. Переписан метод xmlToArray на основе DOMDocument, что позволило парсить атрибуты у XML тегов, у которых указан контент. Контент теперь хранится в ключе массива @content, если у тега присутствуют атрибуты.

По последнему пункту: в связи с этим у некоторых пользователей могут слететь поля guid, которые указываются и с атрибутом, и с контентом внутри, одновременно. Для этого достаточно переписать получение этого поля на:

@INLINE {$guid['@content']}