Альтернативные способы работы с XML. Часть 3: Введение в XSL-преобразования или трансформация XML



В современном IT мире XML является универсальным средством хранения и доставки информации. Он широко используется как в настольных приложениях, так и при веб-разработке, поддерживая парадигму MVC (model-view-controller), которая означает использование разделения логики работы с данными, пользовательского интерфейса и их взаимодействия при создании приложений. Т.о. XML с точки зрения MVC является одним из вариантов обеспечения функции взаимодействия между данными и пользовательским интерфейсом.

В современном IT мире XML является универсальным средством хранения и доставки информации. Он широко используется как в настольных приложениях, так и при веб-разработке, поддерживая парадигму MVC (model-view-controller), которая означает использование разделения логики работы с данными, пользовательского интерфейса и их взаимодействия при создании приложений. Т.о. XML с точки зрения MVC является одним из вариантов обеспечения функции взаимодействия между данными и пользовательским интерфейсом.

Особенно отчетливо это прослеживается в веб-приложениях, когда серверная процедура, обрабатывая некую бизнес-логику (данные), отдает другой серверной процедуре (или клиенту) результат в виде XML. Эта процедура в свою очередь получает XML, разбирает его по определенным правилам и формирует готовый HTML-код веб-страницы, для отображения пользователю. Такой подход значительно упрощает поддержку подобных приложений, особенно если проект сложный. Он позволяет разным специалистам сосредотачиваться только на своих зонах ответственности: программисты отвечают за обработку данных и выдачу результата, верстальщики эти данные визуализируют.

Разбирать XML по определенным правилам можно с помощью серверного языка программирования, а можно сделать трансформацию при помощи шаблонов XSL и получить на выходе готовый результат. Выходным результатом может быть не только веб-страница на языке HTML, при помощи XSL данные одного XML-файла можно переложить (трансформировать) в другой, с совершенно другой структурой. Нас с вами интересует именно последний вариант, поскольку 1С не предназначена для написания веб-приложений.

Как правило на практике разработчики 1С не сталкиваются с применением этой технологии. В принципе, это оправданно, ведь для решения повседневных задач клиентов достаточно использования последовательного построчного чтения XML с помощью объекта ЧтениеXML. Но всегда бывает полезно знать чуть больше. Цель статьи — познакомить незнакомых с технологией XSL преобразований 1С-ников. Как эту технологию применять на практике — тут каждый решит сам.

В качестве примера могу привести собственную разработку Анализатор мобильной связи. В программе есть модуль загрузчиков файлов с детализацией разговоров разных операторов сотовой связи. Порой приходится иметь дело с самыми запутанными XML-файлами. Разбирать такие файлы последовательным чтением довольно трудоемко, поэтому для таких случаев я применяю либо технологию xPath (специальный язык запросов к XML) для разбора файла либо трансформирую исходный XML при помощи преобразований XSL в удобный для последовательного чтения XML. Первый вариант описан в предыдущей публикации Введение в xPath или запросы к XML, а о вторым речь пойдет дальше. Оба варианта базируются на объектной модели документа DOM. Если вы еще не знакомы с этим понятием, то можете прочитать статью Введение в DOM или объектная модель документа XML.

Для преобразований XSL в 1С есть специальный объект ПреобразованиеXSL (процессор преобразования). На вход этому объекту подается исходный XML и шаблон-правило преобразования. По сути шаблон-правило это тоже XML с набором инструкций процессору преобразования. Говоря простым языком, эти инструкции определяют, какие данные и откуда нужно взять из исходного файла и как их структурировать в результирующем файле.

Пример работы с преобразованием показан ниже.

Код 1с для преобразования xml

Все, что начинается с «xsl:» — это инструкции процессору преобразования. Остальное включается в результирующий файл как есть.

Разберем инструкции и теги по порядку (отмечены красными цифрами):

  1. Это стандартная инструкция, обязательная для шаблона. Она задает относительный путь (ветку тегов) к которому будут применяться другие инструкции. В нашем случае — это корень (самый верхний тег) исходного файла xml.
  2. Определяется верхний тег phones для результирующего xml.
  3. Задается поиск цепочки тегов Array-Bill > bill > subs (логически это означет найти детальную информацию всех телефонных номеров) относительно корня исходного файла XML. Таких цепочек может быть множество. Поэтому инструкция for-each задает их циклический обход.
  4. При обходе каждой найденной в п.3 цепочки в результирующем XML внутри тега phones будет создаваться тег phone. Инструкция attribute name=»id» привязывает к тегу phone атрибут id. Значение атрибута определяется следующей инструкцией value-of select=»msisdn», которая определяет, что нужно внутри полученной цепочки Array-Bill > bill > subs найти тег msisdn (логически — это номер телефона) и подстваить его значение.
  5. Инструкиция copy-of select=»s_det/crg/*» определяет, что внутри полученной цепочки Array-Bill > bill > subs необходимо найти цепочку тегов s_det > crg (логически эта цепочка ведет к расходам по конкретному телефонному номеру) и все теги внутри этой цепочки скопировать как есть в результирующий xml внутрь созданного в п.4 тега phone.
Теперь давайте разберем на простом тестовом примере возможности преобразования. В реальной жизни XML может быть гораздо более сложной структуры.
 
Подав на вход вышеописанного преобразователя XML следующего содержания:
 
xml источник
 
и применив описанный шаблон, в результирующем XML получим:
 
результирующий xml
 
Т.о. в результирующем XML отсутствуют ненужные для разбора теги, остались только те, которые имеют для нас значение. Структура тегов стала более удобной для последовательного чтения и разбора.

7 Comments

  1. СергейКа

    Тема хорошая, интересная, полезная.

    Но разбита на такие кусочки, что отбивает желание плюсовать.

    Reply
  2. Sherlock_kmw

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

    Reply
  3. СергейКа

    (2) Вот файлик бы со всем этим в одном я бы скачал 🙂

    Согласен с тем, что если информации много, то это не читабельно в одной статье. Но есть же пределы…

    Reply
  4. gaglo

    Тема интересная. Но поскольку описано уже два метода, хотелось бы иметь и рекомендации насчет применения — когда xPath? когда XSL? Хотя бы намёком. Уж если автор сам пишет, что применяет и то, и другое…

    Reply
  5. kapustinag

    Полезная информация, и спасибо за конкретный пример применения.

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

    К тому же это структурирует и последующую дискуссию — вместо обсуждения XML вообще будут обсуждения в соответствии с конкретными темами статей.

    Reply
  6. Новенький_2209

    Тема крута и автор молоток. Имхо, нужно соблюдать некую грань между производительностью и легкостью модификации решения/времени затраченное на модификацию и разработку. В случае сабжа — простым вещам — да. Сложные — один раз сделал, залил в бетоне и забыл. Твой приемник — все сотрет и перепишет циклами, т.к. в нашей 1сной экосистеме пока это не прижилось на массовом уровне. Кроме того, естественно если база — клиент-серверная и XPATH и XSLT нужно юзать в непосредственно на сервере SQL, дергая хранимку, а уже резалт — передавать в 1С для анализа.И это еще +100500 гвоздей в крышку ящика того несчастного, кто будет это все дорабатывать.

    R.I.P.

    Сам юзал XSLT один раз в жизни, когда одно XML представление, нужно было модифицировать коренным образом в другое. Файло были по 70 метров в среднем. После меня, следующий прог — все стер и написал без XSLT и запросов. Многа-многа кода в регламентном задании ночью — зато он понимает как работает и смог убедить руководство, что мое решения — овнянское, а его — торт! Но правда у меня преобразование шло меньше минуты, а у него — ночью. А ночь — темная в средней полосе, спешить некуда особо 🙂

    Reply
  7. vdmkvrshn

    Я вообще фанат этой технологии!! 🙂 С ее изучением я полюбил работать с XML. Писал на ней обмен между типовым решением центральной базы и мобильным приложением: никаких тонн кода — все просто и кратко. Другой программист пришел — смотрит на это, как на нечто магическое, но придерживается правила «работает — не трогай». Если что-надо допилить, обращаются ко мне))

    Вообще, часто применяю это при загрузке данных с каких-то сайтов: одним действием выдергиваешь из входящей XML-ины нужный кусок и преобразовываешь его в сериализованный объект 1С — массив, структуру, таблицу значений. Потом десериализуешь тоже одним стандартным методом глобального контекста. И профит — работаешь уже со стандартной коллекцией 1С. Модифицировать и отлаживать в разы проще, чем запутанный клубок циклов и условий, который ломается при каждом незначительном изменении структуры входящего файла.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *