В современном 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 с набором инструкций процессору преобразования. Говоря простым языком, эти инструкции определяют, какие данные и откуда нужно взять из исходного файла и как их структурировать в результирующем файле.
Пример работы с преобразованием показан ниже.
Все, что начинается с «xsl:» — это инструкции процессору преобразования. Остальное включается в результирующий файл как есть.
Разберем инструкции и теги по порядку (отмечены красными цифрами):
- Это стандартная инструкция, обязательная для шаблона. Она задает относительный путь (ветку тегов) к которому будут применяться другие инструкции. В нашем случае — это корень (самый верхний тег) исходного файла xml.
- Определяется верхний тег phones для результирующего xml.
- Задается поиск цепочки тегов Array-Bill > bill > subs (логически это означет найти детальную информацию всех телефонных номеров) относительно корня исходного файла XML. Таких цепочек может быть множество. Поэтому инструкция for-each задает их циклический обход.
- При обходе каждой найденной в п.3 цепочки в результирующем XML внутри тега phones будет создаваться тег phone. Инструкция attribute name=»id» привязывает к тегу phone атрибут id. Значение атрибута определяется следующей инструкцией value-of select=»msisdn», которая определяет, что нужно внутри полученной цепочки Array-Bill > bill > subs найти тег msisdn (логически — это номер телефона) и подстваить его значение.
- Инструкиция copy-of select=»s_det/crg/*» определяет, что внутри полученной цепочки Array-Bill > bill > subs необходимо найти цепочку тегов s_det > crg (логически эта цепочка ведет к расходам по конкретному телефонному номеру) и все теги внутри этой цепочки скопировать как есть в результирующий xml внутрь созданного в п.4 тега phone.
Тема хорошая, интересная, полезная.
Но разбита на такие кусочки, что отбивает желание плюсовать.
Мне же наоборот кусочки нравятся. набор маленьких статей, которые потом автор, возможно, упакует в один красивый файлик
(2) Вот файлик бы со всем этим в одном я бы скачал 🙂
Согласен с тем, что если информации много, то это не читабельно в одной статье. Но есть же пределы…
Тема интересная. Но поскольку описано уже два метода, хотелось бы иметь и рекомендации насчет применения — когда xPath? когда XSL? Хотя бы намёком. Уж если автор сам пишет, что применяет и то, и другое…
Полезная информация, и спасибо за конкретный пример применения.
А то, что тема раскрыта в нескольких статьях — лично у меня никаких претензий. Вряд ли на такой разбивке можно золотые горы заработать, а тема структурирована хорошо.
К тому же это структурирует и последующую дискуссию — вместо обсуждения XML вообще будут обсуждения в соответствии с конкретными темами статей.
Тема крута и автор молоток. Имхо, нужно соблюдать некую грань между производительностью и легкостью модификации решения/времени затраченное на модификацию и разработку. В случае сабжа — простым вещам — да. Сложные — один раз сделал, залил в бетоне и забыл. Твой приемник — все сотрет и перепишет циклами, т.к. в нашей 1сной экосистеме пока это не прижилось на массовом уровне. Кроме того, естественно если база — клиент-серверная и XPATH и XSLT нужно юзать в непосредственно на сервере SQL, дергая хранимку, а уже резалт — передавать в 1С для анализа.И это еще +100500 гвоздей в крышку ящика того несчастного, кто будет это все дорабатывать.
R.I.P.
Сам юзал XSLT один раз в жизни, когда одно XML представление, нужно было модифицировать коренным образом в другое. Файло были по 70 метров в среднем. После меня, следующий прог — все стер и написал без XSLT и запросов. Многа-многа кода в регламентном задании ночью — зато он понимает как работает и смог убедить руководство, что мое решения — овнянское, а его — торт! Но правда у меня преобразование шло меньше минуты, а у него — ночью. А ночь — темная в средней полосе, спешить некуда особо 🙂
Я вообще фанат этой технологии!! 🙂 С ее изучением я полюбил работать с XML. Писал на ней обмен между типовым решением центральной базы и мобильным приложением: никаких тонн кода — все просто и кратко. Другой программист пришел — смотрит на это, как на нечто магическое, но придерживается правила «работает — не трогай». Если что-надо допилить, обращаются ко мне))
Вообще, часто применяю это при загрузке данных с каких-то сайтов: одним действием выдергиваешь из входящей XML-ины нужный кусок и преобразовываешь его в сериализованный объект 1С — массив, структуру, таблицу значений. Потом десериализуешь тоже одним стандартным методом глобального контекста. И профит — работаешь уже со стандартной коллекцией 1С. Модифицировать и отлаживать в разы проще, чем запутанный клубок циклов и условий, который ломается при каждом незначительном изменении структуры входящего файла.