tenshi ...от XSLT с его "фишками" вроде дизайна, вшитого в код/выборки, от магических "вьюх" и от отсутствия шаблонов как таковых Тем не менее, вы так и не объяснили, как средствами XSLT превратить общепринятый стандарт (BB коды) в безопасный HTML. Я делаю вывод, что XSLT на это просто не способен. А доводить вопрос до абсурда, вместо того, чтобы отвечать, здесь не только вы один умеете. Изменю один шаблон или одну циферку в шаблоне. Все будет работать. "Стораджи" чистить не буду - на спичках не экономят, да и вдруг задание потом снова поменяется на прежнее, такое бывало. Но что будете делать вы со своим XSLT, шаблоны которого, по сути, ничего не могут, и используются как этакие замороченные регулярки? Что, если превьюшки сделать все-таки надо, а страшный и ужасный редизайн не планируется, и ваш слайдер никому нафиг не нужен, особенно посетителям, которым жалко тратить на вас траффик? Что вы будете делать? Пойдете на php.ru и будете там придумывать очередную ситуацию, при которой задача, которую XSLT не умеет решать, не возникает? Ога, конечно. А тащить терабайтами полноразмерные версии файлов на каждый чих - это в порядке вещей. На Гугле сделали редизайн - поменяли размеры превьюшек - выкатили на продакшен - пользователи ломанулись создавать превьюшки - Гугл упал, ога... Несколько сотен превьюшек генерируется за пару секунд. Вы реально боитесь подобных из-пальца-высосанных ситуаций, или просто опять переводите разговор с XSLT на PHP? Вместо того, чтобы ответить уже, как превьюшки создавать в XSLT. (И вообще, как реализовать такую вещь, как pull шаблоны, что вы уперлись в эти превьюшки.) Вообще, на свои вопросы в теме я получил удивительно мало внятных ответов. Создается стойкое впечатление, что XSLT - это что-то вроде религии, где не принято говорить о неудобных вещах, а совершенствование самой технологии подменено ее постоянными восхвалениями. :/
никак. хслт работает с деревьями, а не с текстом. один ли? а должны? задача шаблонизатора - трансформировать внутренний формат во внешний. в гугле превьюшки создаются во время индексирования, а не просмотра пользователем из каких исходников? регистрируется пхп функция, которая будет их делать
tenshi Ну кстати говоря, на большую часть своих вопросов я уже ответил себе сам, поковыряв ваш XSLT пример отсюда - ваших ответов так и не дождался На обстоятельный разбор XSLT-полета я сейчас не способен, напишу, когда будет вдохновение... но если в двух словах - звезда в шоке. На деле все оказалось куда кривее, чем я думал. Жутковатый формат стайлшитов, которые и впрямь являются лишь мутаторами XML->XML... слово "стайлШИТ" для меня приобрело новый оттенок Магическое , повторенное 51 (!) раз для простого сайта - вот уж действительно , все data-теги типа <o:article>, которые так и не вырезаются из окончательного XML, из-за чего любой "атом" данных оказывается обернут дважды, а то и трижды... вообще, конечный XML, который получается после XSLT-сборки - это надо видеть. Сборка менюхи происходит в PHP, хередоками... а мета-заголовки - они уже дописываются к файлу в стайлшите. Запомнили, что где? Таинственные правила типа , стыдливое прятанье части данных через <v:hidden>... короче, ТАКОГО я еще не встречал. Да, и отвечу сам себе (и другим новичкам в XSLT) на вопрос, который я задавал выше: Ответ: данные выводятся в том порядке, в котором выбираются из базы. При использовании SELECT * выводятся все поля выборки, в том порядке, в котором они идут в таблице. Хотите - верьте, хотите - нет.
это плейсхолдер, говорящий "содержимое блока вставлять сюда". кроме громоздкого синтаксиса в нём ничего плохого нет. это концепция вёрстки. к шаблонизации имеет слабое отношение. можно формировать обычный хтмл, коли так хочется это типа плохо? не красиво, да. это был временный хак, который лень было пофиксить. по хорошему, тема тоже должна была бы приходить из хмл, а не привязываться к именам разделов. это данные для роботов, а не для пользователей. строгий хмл - для робтов, гламурный хтмл - для пользователей. чего тут стыдиться? разумется. где-то порядок следования полей должен определяться. у меня это делается во вьюхе, у тебя - в шаблоне в перемешку с прочей логикой отображения и вёрсткой
tenshi Просто получается, что ключевое отличие моих шаблонов и ваших стайлшитов в следующем: - у меня, если взять пустой шаблон, то и готовый HTML будет пустым, соответственно я могу постепенно наращивать его до требуемого вида, и процесс этот не зависит от выборки данных; - у вас, если взять пустой "шаблон" (т.е. стайлшит), то готовый XML тупо отобразит все переданные данные (все-все-все), соответственно чтобы привести его в требуемый вид, надо сначала внести часть представления в выборку, банально чтобы поля шли в нужном порядке и чтобы среди них не было ничего лишнего, и только потом уже можно оформлять шаблон этими вашими правилами морфирования XML. Дело привычки конечно, но второй вариант для меня является настолько диким и неестественным, что вряд ли я на него когда-либо перейду. Я привык к удобству - чтобы шаблоны можно было разрабатывать, даже если данных еще нет, чтобы оформление было в одном месте, а не разбросанным по вьюхе и стайлшитам... наконец, чтобы шаблон был похож на конечную страницу хотя бы внешне, а не на набор операций preg_replace, preg_replace ... preg_replace, чтобы взглянув на него, можно было оценить внешний вид готовой страницы, понять, что где находится.
да, отделение формирования структуры данных от их представления - рулит шаблоны без данных разрабатывать невозможно - рыба нужна по любому. структура данных никакого отношения к оформлению не имеет. обе являются частью отображения. чем больше ты используешь инклудов борясь с копипастой, тем меньше шеблоны становятся походими на целые страницы и больше на отдельные блоки.
tenshi Если оно сделано как надо (формируем данные, не задумываясь о том, сначала на экране идет username, а потом email, или наоборот) - то да. А если через одно место (формируем данные изначально в расчете на конкретный шаблон, для любого другого шаблона выборка работать уже не будет) - то нет. Ошибаетесь. Если есть минимальный опыт дизайна и верстки, то рыба нужна уже далеко не везде и не всегда. А XSLT заставляет тратить на рыбу больше времени, чем на шаблон. Чем больше ты структурируешь свою программу, разделяя ее на классы и пакеты, тем меньше код становится похож на целую программу и больше на отдельные блоки. Все так делают (структурируют работу на небольшие и понятные фрагменты, с которыми удобно работать), только у вас все в одной большой XSLT-куче.
или может быть 2 имейла и ниодного имени, или имейл может быть одновременно и именем. зачем шаблону знать эти нюансы бизнес-логики? а если есть большой опыт, то понимаешь что рыба нужна всегда, причём максимально приближенная к реальным данным. только у нас шаблоны подключаются через "автолоад", а у вас инклудовый ад. у нас полиморфизм, а у вас жёсткая процедурщина. //удалено
tenshi Это другие ситуации совсем, неужели непонятно? Одно дело - добавление нового поля (второй емейл) в базу данных и в логику приложения, и совсем другое - просто поменять на экране два уже существующих поля местами. Одно дело - пересадить сердце от одного человека другому, и совсем другое - снять с одной руки перчатку и надеть на другую, правда ведь? Так вот, вторая операция (поменять на экране два поля местами) должна решаться исключительно шаблонизатором, она не должна приводить к изменениям в бизнес-логике и в программном коде (выборках), иначе это не шаблонизатор, а бред. Никакой это не опыт. Если для того, чтобы правильно сверстать шаблон, вам обязательно нужны продукционные данные, и без них ничего не получается - это как раз говорит об отсутствии опыта. Либо о порочности используемой технологии, которая не позволяет вам даже на секунду абстрагироваться от конкретных данных. Дык у вас все точно так же, только хуже. Вместо того, чтобы явно вызывать шаблон для вывода данных там, где это нужно, вам приходится копировать "путь" к этим данным в DOM и писать для этого пути отдельный обработчик. Получается та же самая "процедурщина" и "инклудовый ад", разве что разбираться и отлаживать вашу писанину сложнее, потому что управляющий код не находится перед глазами, а спрятан ХЗ где, может быть, он в одном XSLT файле, может быть, в другом, а может быть, в десятом. Вы ничего не поняли, это были скрижали от Моисея, они в аргументации не нуждаются
ага, значит слова кончились, перешли на оскорбления. Вот видите tenshi, вы не в состоянии даже осознать простейщие, истинные, вещи. А ещё пытаетесь нам повествовать о каких-то высоких материях. надменный. ничего, со временем, с опытом, это пройдет.
все однотипные операции должны происходить в одинаковых местах, а не быть разбросанными по всей программе. распространённый пример: верстали с именем из 10 букв и всё было хорошо, пришло имя из 15 и всё поехало. или наоборот - выводили 3 знака после запятой, а приходят сплошь целые числа - получили мусор в виде ".000". без _реальных_ данных что-либо делать вообще бесполезно. большие возможности требуют большей ответственности. у меня всё чётко структурировано. это было не оскорбление.