Готовое решение: PHPC — PHP Compiler CMF

tenshi

Просто вы явно не понимаете, что в моем движке можно, а что нельзя. Значениями параметров могут быть любые строки, хоть бинарные. Правила экранирования - как у double-quoted строк в PHP. И это делает их крайне мощными: хотите - передавайте теги (param="<Читай>"), хотите - передавайте HTML-сущности (param="&lt;Читай&gt;"), хотите - передавайте и то, и другое. У шаблона есть две стратегии работы с переданными параметрами:

- экранировать их перед выводом (стратегия по умолчанию, уже экранированные символы повторно не трогаются);
- тупо выводить все как есть (нужно вместо <vararam> писать в шаблоне <vararam nofilter>).

То есть в PHPC для любого параметра существует выбор между безопасной стратегией (экранирование) и более опасной (что передали, то и имеем). В XSLT же выбора нет - там только "опасная" стратегия. Если я напишу в XML опасный тег (<script>...</script>), он и вывалится тупо на экран - привет, XSS! Чтобы обезопасить данные, мне нужно самому вручную экранировать их в XML - геморрой. В то же время из-за ограниченного синтаксиса XML нет возможности передать "опасные" данные и возложить их экранирование на движок - ваш XML просто вывалится с ошибкой на фрагменте "<Читай>", приняв его за "невалидный тег". А ведь кому-то может быть удобно использовать такие символы в заголовках.

Вывод: это XSLT заставляет вас ковыряться в "экранированном хмл-е", а не PHPC. Да, это сомнительное удовольствие, согласен.

Я эту обработку давно написал, а у вас пока одни пустые слова.

Не спорю. Я это приводил к тому, что слова про "сложность (шаблонов) растёт экспоненциально" - глупость, если конечно не валить все в одну кашу, а структурировать. В PHPC все возможности для структурирования есть.

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

Ога. Правда, момент с перестановкой двух полей местами мы с вами уже рассматривали в соседней теме

Да как же нет? Все там есть, именно такие дикие пути там и есть. У вас все правила морфирования начинаются с одного и того же

Код (Text):

1. <t:template match=" /o:data/o:track-list/o:track/o:descr ">

, где между кавычками прописывается этот кошмарный путь. И у каждого правила он другой, и редко когда эти правила меньше тройной вложенности. Это типа нормально для XSLT?

Здрасте, я ваша тетя! С plain-text письмами все ясно (я о них и не упоминал), а вот в XML все прекрасно поддерживается и работает.
Простой пример, учим матчасть. Специалисты по XML епт

И не надо. Я свой движок писал не для того, чтобы его "правили под себя", а чтобы им пользовались.

Во-первых, работа с УРЛами у меня автоматизирована, все запросы обслуживает один "реврайт", а вовсе не туча. Во-вторых, никакой "привязки к иерархии" у меня по умолчанию нет: хотите - привязывайтесь в своем проекте, хотите - используйте самые короткие УРЛы. В-третьих, вы явно не понимаете разницу между понятиями URL и ID. Первое имеет осмысленную для человека форму и потому может измениться (например, исправлена опечатка, которых у вас в базе хватает, или статья была дополнена и ей нужно более общее название), как следствие - эту строку нельзя использовать для связей между таблицами, она не неизменна. Второе - это значение, которое не имеет осмысленного вида и никогда и ни при каких обстоятельствах не изменяется, как следствие - это значение можно использовать для внутренних связей. Что немаловажно, выборка, в т.ч. индексированная, по числовым ключам гораздо быстрее выборки по строке.

Статью я читал, сама статья неплохая, но однобокая. Автор забыл про один важный аспект ЧПУ: они должны легко набираться с клавиатуры по памяти, а иначе какой смысл делать адрес простым и коротким? У вас все УРЛы имеют вид типа "?article:uuu.hell", то есть, кроме букв, используется как минимум три разных знака препинания, что делает такие адреса совершенно бесполезными для запоминания. Все равно потом правильно не наберешь. Такие адреса годятся только для кликов по ним мышкой, то есть смысл ЧПУ как таковой теряется.

 

tenshi

Уже экранированные символы не трогаются. "&amp;" останется "&amp;", и на экране это будет выглядеть, как просто "&".

Да сколько ж раз повторять-то? Можно! Можно использовать теги. Например:

HTML:

1. <insert:htmlMenuItem link="/" title="<b>Читай</b>"/>

Да никакой не сложный. Все расширяется элементарно, ведь шаблоны в PHPC - это очень мощная вещь, в них можно проверять произвольные условия, можно вставлять другие шаблоны, можно наследовать их друг от друга, можно использовать PHP-вставки и так далее. А вот как расширять шаблоны в XSLT? Можно конечно сделать кучу проверок, привязавшись к DOM пути, и для каждого случая наделать обработчиков - для верхнего уровня один, для вложенного другой, но если потом понадобится чуть изменить структуру данных (например, меню перенести из верхнего уровня в какую-нибудь боковую панельку), у вас же все придется переписывать под корень.

По-моему, это жутко неудобно. Смотрим в XML - и одновременно на бумажке записываем путь (начиная с текущего элемента, то есть с конца, и постепенно поднимаясь до корневого элемента), а потом в текстовом редакторе делаем Ctrl+F и вводим этот путь, чтобы найти в файле искомый шаблон-мутатор...

Кстати, а что случится, если в XSLT окажется два правила для одного и того же DOM-пути? Применятся оба? В каком порядке? Опять же неудобство - один разработчик написал один мутатор, второй, не разобравшись, добавил еще один, и очень быстро код превращается в помойку. В случае нормальных шаблонизаторов существование двух шаблонов с одним именем невозможно в принципе (это либо файл, либо уникальная запись в таблице).

Ссылка на вики - не совсем то. Это именованные сущности... их вроде как тоже можно использовать в XML, если совсем приспичит, но надо как-то предварительно "объявлять". Числовые сущности работают везде и всегда.

Мне было лень

Текст, может быть, и запоминается, а вот с символами беда. Я сейчас, не перечитывая свою мессагу, уже не скажу по памяти, где там что было - где было двоеточие, а где запятая (или точка?). Имхо, в URL есть только один символ, который знают и помнят все - это слеш (/). Все остальное от лукавого и никому не надо.

А то, что на всем сайте единые правила - ну еще бы они в пределах сайта различались Да только на одном сайте одни правила, на другом другие... люди не обязаны запоминать все эти тонкости.

 

tenshi
С-ответом-тормозящий, словонеохотливый мультипостер

Понял ничего. Еще раз то же самое, пожалуйста, только понятнее.

Зато у меня по крайней мере все, что отвечает за один шаблон - рядом, а не разбросано по десяти местам (хорошо, если не по десяти файлам). Кроме того, напоминаю про механизм наследования шаблонов в PHPC - специально для тех, кому не нравятся проверки условий.

Вы помните, с чего вообще начался этот наш разговор про HTML-сущности? Напоминаю:
ВЫ: Если у тебя win1251, как же ты хранишь иероглифы? HTML-сущностями?
Я: Да, и ничего плохого в этом не вижу.
Не знаю, что в тот момент под "HTML-сущностями" подразумевали вы, но я имел в виду и именованные сущности, и числовые (по-вашему - "ссылки на символы", хотя в оригинале это называется Numeric Character Reference). Для того злосчастного иероглифа именованной сущности, насколько я понимаю, не существует вовсе. Так что выбора нет - только число. Которое, еще раз повторяю, работает везде и всегда. И ради сомнительного удовольствия записать эту зигогулину не шестью байтами, а тремя (экономия аж 3 байта!!!) переводить ВСЮ базу в более расходную и медленную, а главное - нестабильную, многобайтовую кодировку, лично я смысла не вижу никакого.

Если речь не о ручном наборе УРЛа, то статья теряет всякую ценность. Ибо без ручного набора на внешний вид ссылок всем глубоко плевать. Постоянные посетители - тоже, кстати, немаленькая ценность. Я бы даже сказал, большая. Ради них можно и продумать архитектуру сайта немножко.

 

tenshi

Это у вас пользователь вводит "&amp;" а получает просто "&".
У меня пользователь вводит "&", и получает на экране "&".

Да, позволяет.

Да, хороший, ибо в 1251 эти символы есть.

Строка в однобайтовой кодировке всегда корректна, ибо допускаются все 256 вариантов для каждого символа.
А строку в UTF8 можно запросто запороть. Один substr вместо mb_substr, и все. Порченая строка может быть легко передана и снаружи. Вы хоть в одном своем проекте на UTF8 выполняете строковую валидацию входящих данных? Я говорю не об обычной валидации, типа "не более 100 символов" или "только буквы и цифры", а именно о валидации внутренней структуры самой строки. А нормализацию, чтобы минимизировать неоднозначности? Если нет - поздравляю, ваши проекты дырявы. Например, MySQL не принимает порченые UTF8-строки в запросах, в лучшем случае выдавая ошибку всего запроса. А до недавней версии так и вовсе намертво зависал на них.

...с тремя разными знаками препинания в них. Имхо, все, что кроме слеша - уже не к месту. Даже всяких тире и подчеркиваний нужно стараться по возможности избегать.

 

iliavlad
tommyangelo
www.phpc.ru/manual - вот тру человекопонятный УРЛ.