Запись опубликована FotoV.net. Пожалуйста, оставляйте комментарии там.
Озадачился я вопросом - а что такое “шаблонизаторы” и какой в них смысл?
Полез читать, да все как-то про “сипульки для сипуления в сипулярии”. Но за пол-дня в общем и целом начал осозновать, что именно имеют некоторые, говоря об отделении логики от представления и благе шаблонизаторов для больших проектов, где не нужно дергать кодера для того чтобы что-то где-то поправить, мол - “дизайнера это работа”.
Вся сложность восприятия этой темы возникает лишь из-за того, что есть настоящие шаблонизатор - например XML -> XLST -> “Привет мир!” и многие другие, по факту являющееся библиотеками расширения языка.
Что я хочу этим сказать? Да то что Smarty к примеру - не шаблонизатор, а лишь библиотека акронимов, позволяющая писать (я не знаю ни PHP ни Smarty, это лишь попытка объяснения на пальцах, не приставайте к коду)
{foreach from=$data item="entry"}
<div>
{$entry.Comment|escape}
</div>
{/foreach}
Вместо
<?php
//... а здесь мы пишем функцию, которая читает из базы и последовательно вставляет полученное нами в
$output = $output.'<div>'.$entry.'</div>'
//... и делает это наверное в цикле
?>
Т.е. разделения логики и отображения не происходит - мы просто используем расширение языка. Мы обязаны быть в курсе, какие именно переменные и в каком виде (какого типа) у нас возвращаются из основного кода, после чего в “шаблонизаторе” мы эти переменные используем для отображения.
Сериализации данных не происходит, а лишь сериализация позволяет гарантировать ”чистоту” данных от логики источника. Я не говорю о том, что в сериализованных данных не может содержаться какой-то код, я говорю о том, что он перестает быть исполняемым. Адресат данных должен самостоятельно решать, как именно будут восстановлены полученные им данные, в “предложении” же должны содержатся как минимум и подлежащее и сказуемое для возможности самостоятельного восстановления сути сказаного. Содержащиеся данные не “подразумевают” чего-либо еще или не умалчивают о чем-то, они ровно то, что они есть.
Ну например, если принять выражение -“Эта булка стоит 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, они же уже “накололись” на этом и больше так не “лохонутся”. Ну, тогда перечитайте еще разок этот опус или попробуйте написать гневный отклик на него, думая над каждой своей фразой.