Pull to refresh

Суровые челябинские 1С-разработчики и как же юзать XSLT

Reading time 6 min
Views 1.5K
Озадачился я вопросом — а что такое «шаблонизаторы» и какой в них смысл?

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

Вся сложность восприятия этой темы возникает лишь из-за того, что есть настоящие шаблонизатор — например XML -> XLST -> «Привет мир!» и многие другие, по факту являющееся библиотеками расширения языка.

Что я хочу этим сказать? Да то что Smarty к примеру — не шаблонизатор, а лишь библиотека акронимов, позволяющая писать (я не знаю ни PHP ни Smarty, это лишь попытка объяснения на пальцах, не приставайте к коду)
{foreach from=$data item="entry"}
{$entry.Comment|escape}

{/foreach}

Вместо
<?php
//... а здесь мы пишем функцию, которая читает из базы и последовательно вставляет полученное нами в
$output = $output.''.$entry.''
//... и делает это наверное в цикле
?>

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

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

Ну например, если принять выражение -«Эта булка стоит 5 рублей!» за сериализованное, то варианты несереализованных выражений будут такими — «Это стоит 5 рублей! (Что?)», «Булка стоит 5 рублей (Какая?)», «Эта булка стоит 5 (Чего?)», «Эта булка — 5 рублей!(Местная валюта-хлеб?)» ну и апофеозом будет «Это стоит денег (???)» и «Смотрите прайс-лист! (wtf?!)».

Smarty позволяет разработчику сказать что-то типа "-Эта булка стоит 5 тышш рублей, потому что мы — пафосный бутик на Тверской!" и следует принимать решение на основе полученных от него данных и находясь в границах его логики. То есть начать соображать "- А, этож Тверская, тут же все дорого, значит надо баблос слюнявить как сказали".

Сериализация позволяет отстранится от логики источника и вполне обосновано предположить "- Дороговато!", соотнеся услышанную стоимость со своим представлением о том, чего должен стоить хлеб, после чего вежливо поинтересовавшись, не отведывали ли тут рыбного супа предложить продавцу отправиться налегке в пешее эротическое путешествие.

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

Отлично, мы прониклись идеей, что «сериализация» есть благо, но при чем тут 1С?

Ну, они похоже этой идеей просветлились, во всяком случае г-н Рыжиков, создавший незабвенную виршу Иллюзии XML/XSLT технологий. Я лично смутно себе представляю, сколько и чего нужно раскурить, чтобы «я сам программист», прочитавший
много книг и учебников, в которых программистов и проектировщиков учили, что лучший способ создать шаблонизатор или абстрагировать внешний вид (представление) от данных — это загнать все в XML, пропустить потом через XSLT и уже на выходе получить HTML.

наложил табу на back-end логику и
Все восприняли это буквально и начали делать подобные продукты. Ну и конечно мы тоже наслушались и уверовали, что наше будущее — это XML/XSLT технологий.
Совершили подвиг, заставив XSLT шаблоны работать достаточно быстро, вложили кучу сил, времени и денег в разработку технологии… Самые большие каталоги товаров вмещали по 70 тысяч товаров.

сделал вывод, что:
Как не стараются РАЗРАБОТЧИКИ, производительность XML/XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей структуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных, получая на выходе опять же текст, который занимает память.

При этом искренне не понимал о чем идет речь, когда ему задавали вопрос — «Откуда берутся огромные объемы данных, если контента на страницу бывает кило 100 максимум???».

Действительно, как же не взяться огромным объемам, если обрабатывать xml-дамп базы XSL-шаблоном?

Безумству храбрых поем мы песню!

Не менее весело читать «независимых разработчиков», которые согласны с мэтром — «XSLT — тормоза и отстой!».

Нет, ну вообразите себе — это ровно (в смысле абсолютно эквивалентно) как наткнутся в ЖЖ на топик
-Сегодня взялся за голые провода, стоя в мокрой ванне. Нехило меня током долбануло, 3 часа в себя приходил!

с толпой комментов:
— И я сегодня взялся за провода! И меня долбануло!

-+1, ванны отстой! Резиновые коврики рулят!

— Резина — отстой, лучше пластик!

— Сам ты отстой, и пластик твой — фуфел!

— Ответил за базар, что пластик — фуфел?

— Ха, да у меня друг — директор шинного завода, они там только резину и юзают, а не какой-то говнопластик. Не надо же тебе объяснять, как это круто — делать шины! Это не какой-то там свечной заводик в Урюпинске, это же production!

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

— Да ты лошара, вот меня один раз долбануло в ванне от проводов, так я нахрен их вырубил в щитке в подвале! Чтоб ни меня, не мою семью, ни соседей не било! Надо же и об окружающих думать!

Клиника, одним словом :)

Пожалуйста, не делайте так!

Шаблон должен делать ровно то, что он делает — взять с полки и укомплектовать товар аксессуарами, в зависимости от того — OEM это или Retail. Если Retail — то и диск положи, и шлейфы и мануалы на всех языках, и брелок. А если OEM — чихни в пакет для комплекта к самой железяке. При этом комплектовщик работает с конкретной железкой и каким-то конечным объемом аксессуаров, подходящих к этому устройству. Он не пытается запихнуть в коробку с видеокартой блок питания, потому что у нее есть дополнительный разъем — блок питания не входит в комплект по его ТИ, или вместо видюхи положить бутылку коньяка, метнувшись за ним в магазин, потому что это для «самого». И уж тем более ему не говорят — «Вот видюха, вот склад комплектов — выбери чего-нить и сунь туда, ты же головастый малый!»

Разделение логики означает ее, логики, разделение — не более и не менее!
(если Вас передернуло от такой формулировки — просто проигнорируйте, а если какая-то смутная догадка мелькнула в мозгу — перечитывайте до просветления)

У вас все еще есть база SQL с хреновой тучей записей (как и положено приличной SQL-базе); back-end который ходит в базу и получает от нее полтора десятка записей (в соответствии с запросом пользователя и логикой постраничного отображения, предписывающего отображать 15 записей, причем в названии не должно быть слова «Жопа» если в графе «Возраст» у юзера стоит «до 18») на выходе заворачивающий результаты своей работы в XML; front-end получающий коротенький XML и накладывающий на него свою таблицу стилей ака XLST в результате чего получается новый XML-файл, в котором первоначальный узел <bullshit>Костюм и галстук — $5000</bullshit> меняется на <Haute couture>Костюм и галстук — $5000</Haute couture>.

А где же HTML? Да здесь он, родимый, просто в другом шаблоне — toHTML, для узла <bullshit> задано другое правило, трансформирующего его в <span class=«amazing» >, которое отдается клиенту тем же front-end-ом, если пользователь не умеет читать XML. Да, суть front-end-а именно в том, чтобы говорить с клиентом на одном языке, при этом ему пофигу о чем ведется речь — про шмотки или бухло. Он и о том и о том может, если суфлер-back-end подскажет, что вставлять после «Это очень крутая штука, наша»…

Короче, если Вы смогли это дочитать и все еще пытаетесь реализовать back-end как XLST-преобразование XML-дампа базы данных — прямая дорога вам в 1С, делать «Битрикс-ы» под руководством г-на Рыжикова. Или нет, не возьмут Вас за слова XML и XSLT, они же уже «накололись» на этом и больше так не «лохонутся». Ну, тогда перечитайте еще разок этот опус или попробуйте написать гневный отклик на него, думая над каждой своей фразой.

UP. Disclaimer — сложность текста, его сумбурность, оторванность примеров от предмета и тэдэ — результат крайне поверхностных знаний автора в обсуждаемом предмете. На данный момент вся моя профессиональная подготовка по XLST состоит в прочтении первого предложения XLST — стандарта, гласящего:
This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents.

Еще вопросы?
Tags:
Hubs:
+13
Comments 19
Comments Comments 19

Articles