Хм, на сайте сказано инет стоит 3 руб в день = 900 руб в месяц. Не очень выгодно, учитывая, что у мегафона я беру за 450руб с намного большим покрытием.
Забавно, только недавно хотел вернуться к своему давнему проекту, который интерпретирует любую PHP либу в си, так что бы можно было собрать расширение для PHP в виде SO файла. Все распланировал, продумал и даже придумал как быть с yield в сях. Однако теперь и не знаю, стоит-ли дальше развивать проект?
Вас тоже этот вид raw, через модификатор, ввело в заблуждение.
Дело в том, что у twig не важно на какую переменную применен модификатор raw — ожидаемого воздействия не будет. При включенном экранировании, для тегов
будет иметь нужное нам значение, что очень похоже на мой реализованный вариант. Я просто предложил более прозрачный вариант, воздействие может быть только на тег целиком, поэтому пусть тег и указывает тип воздействия.
{verbatim} не то другое, это как {literal} в Smarty или {ignore} в Fenom — игнорирование тегов шаблонизатора.
Я изначально считал raw, как модификатор, не лучшим вариантом. Неоднозначность ситуции {«Text» ~ $var|up|raw ~ $value|low} или схожих может привести к не пониманию и путанице. Так же модификатор не применить к inline или блоковой функции. Raw, по сути, упаравление потоком, делать через модификатор я считаю, мягко говоря, не корректно, так как модификатор меняет значение переменной непосредственно, а не управляет шаблонизатором. В предложенном мной варианте явно указано что raw применяется к тегу вцелом.
" те же способы доступа должны равноценно работать для массивов, объектов"… " достаточно ресурсоемкая задача", а не проще контролировать входные данные в шаблон? Шаблонизатор у меня зародился по одной простой причине, я всегда уверен какие данные отдала система в шаблон и мне не нужен огород из проверок. Поискав по интернету, таковых шаблонизаторов (которые не считают себя умнее разработчика) я не нашел… поэтому взялся за молоток клавиатуру, но азарт разработки поглатил меня и вышло нечто большее чем примитивный шаблонизатор. Тем неменее идею я оставил: ваши данные — ваша ответвенность.
Отчасти вы правы, если шаблны простые. Я тоже так полагал, что проще проверить пхп код, однако вот как вышло. Вставка переменных еще не плохо анализируется, однако когда нужны различные модификаторы, начинается пляска. Например, то что обычный модификатор в шаблонах на самом деле не простая функция с несколькими аргументами которая может поступить не тривиально при не правильных условиях и использовании. Код начал множиться и усложнять, да так что через некоторое время даже разработчик не понимал что там происходит. Я все-таки за шаблоны, НО при компиляции, которые, превращаются в тот пхп код который бы вы сами написали, если бы писали шаблон на чистом пхп. Я шаблонизатор рассматриваю как преобразователь некой разметки в качественный и быстрый PHP код.
Конечно, если у вас простейшая шаблонизация то не стоит и запариться — используйте PHP :)
По поводу транслитерации в си, у меня давно начата наработка в виде Toxen (поэтому я и изучал расширение tokenizer), который позволит превратить любую PHP либу в расширение (fenom.so, symfony.so, yii.so итп), но увы, катастрофично не хватает времени.
Добавил raw и autoescape. Довольно быстро и легко, с проблемами которые Вы описали не столкнулся. Про проверку переменной это отдельная история, переменные у меня берутся через один код — Fenom\Template::parseVar() добвить туда тернарник не проблема, задача пока висит из-за написании тестов.
Мне кажется Вы слегка нагнетаете, если архитектура проекта проста и ясна, то добавить хоть самый изврат — не проблема.
Шаблонизатор только-только и печи и сейчас не пертендует везде на полную замену популярных шаблонизаторов. Все приходит со временем. Со временем я добавлю более боевые тесты и больше функциональности. А пока я приглашаю поучавствовать в развити проекта.
Не стоит удивляться. Я, конечно, был в курсе об автоэкранировании, но работая в highload проектах, данные подготавливаешь заранее потому что производительнее заэкранировать один раз данные перед сохранением в базу, чем экранировать каждый просмотр. Если сделать холодный расчет: 0.1ms занимает экранирование, допустим элементов отображается 50 на страницу, есть заголовок, описание и еще 3 текстовых поля у каждого элемента. Это 0.1 * 50 * 5 = 25ms, итого +25ms ко времени загрузки страницы, что довольно существенно для highload. Тем не менее я добавил экранирование, но по умолчанию эта опция выключена.
Дело в том, что у twig не важно на какую переменную применен модификатор raw — ожидаемого воздействия не будет. При включенном экранировании, для тегов
{{ "data: " ~ a|upper|raw ~ b|lower }} {{ "data: " ~ a|upper|raw ~ b|lower|raw }} {{ "data: " ~ (a|upper|raw ~ b|lower)|raw }}результат будет один:
модификатор игнорируется.
Только
{{ ("data: " ~ a|upper|raw ~ b|lower)|raw }}будет иметь нужное нам значение, что очень похоже на мой реализованный вариант. Я просто предложил более прозрачный вариант, воздействие может быть только на тег целиком, поэтому пусть тег и указывает тип воздействия.
{verbatim} не то другое, это как {literal} в Smarty или {ignore} в Fenom — игнорирование тегов шаблонизатора.
молотокклавиатуру, но азарт разработки поглатил меня и вышло нечто большее чем примитивный шаблонизатор. Тем неменее идею я оставил: ваши данные — ваша ответвенность.Конечно, если у вас простейшая шаблонизация то не стоит и запариться — используйте PHP :)
По поводу транслитерации в си, у меня давно начата наработка в виде Toxen (поэтому я и изучал расширение tokenizer), который позволит превратить любую PHP либу в расширение (fenom.so, symfony.so, yii.so итп), но увы, катастрофично не хватает времени.
Мне кажется Вы слегка нагнетаете, если архитектура проекта проста и ясна, то добавить хоть самый изврат — не проблема.