Озадачился я вопросом — а что такое «шаблонизаторы» и какой в них смысл?
Полез читать, да все как-то про «сипульки для сипуления в сипулярии». Но за пол-дня в общем и целом начал осозновать, что именно имеют некоторые, говоря об отделении логики от представления и благе шаблонизаторов для больших проектов, где не нужно дергать кодера для того чтобы что-то где-то поправить, мол — «дизайнера это работа».
Вся сложность восприятия этой темы возникает лишь из-за того, что есть настоящие шаблонизатор — например 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.
Еще вопросы?
Хорошие новости! ОБТ 3 начался!
