Существует ли Blitz на php ?

weregod

unserializer
Автор оригинала: Lightning
weregod
Само по себе создание языка шаблонов поверх PHP не решает описанную табой задачу.
Решает, если оставить конструкции только типа IF и FOREACH

Автор оригинала: Lightning
Чтобы редактировать шаблоны на PHP или на каком-либо языке шаблонов, человек должен понимать что такое ветвления и циклы. Если он этого не понимает, то блочные шаблоны ему в руки. А блочные шаблоны тоже можно реализовать на нативе. А можно зачем-то использовать специальный блочный шаблонизатор...
И как Вы предлагаете при использовании натива избежать инструкций
die
while (true){}
unset(какой-нить архиважный объект для системы)
....
?

Автор оригинала: Lightning
При чем тут вообще CMS. В своей CMS ты можешь вообще сделать так, чтобы пользователь мог выбирать шаблонизатор.
Чем увеличить количество тикетов?

Автор оригинала: AmdY
да я тогда уже сразу буду эти шаблоны evalлить.
ты слишком хорошего мнения о пользователях, подавляющее большинство не может даже wysiwyg освоить, а шаблоны редактировать ....
При выборке из десятков тысяч абсолютные количества сказочных долбо..бов или просто пытливых умов велики.

В случае отдельного проекта, контентмэйкером и редактором шаблонов которого является сам разработчик или конкретная группа людей, обладающих требуемыми знаниями, в нативе ничего плохого нет, его ненужно парсить и "компилять" в натив ;)
 

AmdY

Пью пиво
Команда форума
данные приходящие от пользователя нужно проверять, даже если это шаблоны редактируевые в админке. кто мещает оставить только вставку переменных и блоки, и то, их нужно проверять, чтобы не получить нерабочую страницу. причём вставку можно реализовать с помощью плагина к tinyMCE, чтобы пользователь не узнал ни о html, ни о шаблонах.
 

pilot911

Новичок
Автор оригинала: fixxxer
iteration set это структура с рекурсивным определением:
PHP:
<set> ::= array(
    'scalar1' => 'value of scalar 1',
    'scalar2' => 'value of scalar 2',
    ....,
    'block 1' => array(
        0 => <set>,   
        1 => <set>,
        ....
    ),
);
Отбросив вариации на тему 'block1' => <set> (это хак), получаем, что шаблон вида

PHP:
{{ var1 }}
{{ BEGIN A }}
   {{ var2 }}
   {{ BEGIN B }}
      {{ var3 }}
      {{ f_callback(var4) }}
   {{ END }} 
{{ END }}
должен компилиться в нечто наподобие

PHP:
$_ = $this->globals;
$_0 = $this->set;
if (isset($_0['var1'])) echo $_0['var1']; elseif (isset($_['var1'])) echo $_['var1'];
if (isset($_0['A']) && is_array($_0['A'])) foreach ($_0['A'] as $_1):
    if (isset($_1['var2'])) echo $_1['var2']; elseif (isset($_['var2'])) echo $_['var2'];
    if (isset($_1['B']) && is_array($_1['B'])) foreach ($_1['B'] as $_2):
        if (isset($_2['var3'])) echo $_2['var3']; elseif (isset($_['var3'])) echo $_['var3'];
        echo $this->f_callback(isset($_2['var4'])?$_2['var4']:(isset($_['var4'])?$_['var4']:NULL)));
    endforeach;
endforeach;
Компилятор бы я писал на конечном автомате, чтобы не париться с рекурсивными регулярками, которые в pcre в плане пожирания стека шибко злы (не говоря уж о общей долбанутости).
а с fetch() как быть ?
 

fixxxer

К.О.
Партнер клуба
самое простое - отдельно компилировать только нужный блок. в какой нить файлик типа <template-name>.<block-name>.php

то есть получается

protected doParse( $block_name = NULL ){..}

parse() { doParse() }

fetch($block_name) { doParse($block_name) }

-~{}~ 26.03.09 16:17:

ну и даже не blockname а path :)
то есть parse() это по сути fetch('/')

посмотри на прародителя blitz, php templates - там fetch нету, есть parse с аргументом пути по умолчанию корень
 

Lightning

Трудоголик
И как Вы предлагаете при использовании натива избежать инструкций
die
while (true){}
unset(какой-нить архиважный объект для системы)
weregod
1) Парсить и проверять редактированые шаблоны на стороне сервера перед сохранением.
2) Или в админке преобразовывать шаблон в какой-нибудь другой удобочитаемый для пользователя вид, чтобы пользователь вообще не видел натива, а потом преобразовывать обратно.
В своей CMS можно навернуть все что угодно, только нужно ли...
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а вот в 3м Смарти есть поддержка нативного php :)
 

weregod

unserializer
Автор оригинала: Lightning
1) Парсить и проверять редактированые шаблоны на стороне сервера перед сохранением.
зачем парсить натив, когда

Автор оригинала: Lightning
2) Или в админке преобразовывать шаблон в какой-нибудь другой удобочитаемый для пользователя вид, чтобы пользователь вообще не видел натива, а потом преобразовывать обратно.
уже написан шаблонизатор со своим синтаксисом, позволяющий пользователю делать то, что надо, и не позволяющий делать того, что не надо, при сохранении (или обращении, хз, писал не я) "компилирует" в натив.
согласитесь, что натив преобразовывать в "какой-нибудь другой удобочитаемый для пользователя вид" - это уже какой-то бред, так как
1) нетривиальная задача
2) опять лишняя нагрузка на сервер
 

Lightning

Трудоголик
weregod
Я в холиворах не участвую. Делай что хочешь в своей CMS.
И перестань мне Выкать.
 
Сверху