Разделить PHP движок и шаблон

[black.cat]

прдлагаю ТС взглянуть на мой любимый темплейтер
темплейт повер.
Для просмотра ссылки Войди или Зарегистрируйся

очень просто и красиво все работает.

выглядит все примерно так:

include_once( "./class.TemplatePower.inc.php");
$tpl = new TemplatePower( "t.html" ); // это файл шаблона...
$tpl->prepare();

$tpl->newBlock("title");
$tpl->assign("title", $title);

$tpl->printToScreen();

а в html шаблоне все примерно так:

<!-- START BLOCK : title -->
{error_text}
<!-- END BLOCK : title -->

 

[PHP_Master]

XSLT - фу в степени, ездили знаем.
Смысл XSD валидации и т.п. если нормально нельзя отобразить ошибку пользователю - что, конкретно, и на нужном языке, хотя может с тех пор прогресс шагнул дальше, но раньше были невнятные сообщения на англ. языке. Т.е. делаешь 2-ю работу отвалидировал, и если че не так еще должен сам сказать в каком элементе фу...
Я не говорю о том что xml не есть стандартный протокол, т.е. это надо считывать данные преобразовывать в валидный xml вид и конвертить xslем.

Я вижу плюс только в том, что можно на клиенте применять xsl схемы, но тут сразу вопрос оптимизации встает - т.к. тегов как бы и нет в исходном XML. Если добавить в кучу еще отсутствие человечьих циклов, с переменным там какая-та бодяга была (уже не помню) , то лучше не юзать его вообще...

Хотя нет, мелкософтовские доки генерить можно, типа экселек или ворда, без activeХ.

Ты просто не умеешь его готовить.
Прелесть XSLT в том, что:
1. платформонезависим - один и тот же шаблон может использоваться и с PHP и с Python и с Flash и с Java и т.д.
2. обработку шаблонов элементарно можно повесить на отдельный сервер.
3. всё идёт к тому, что обработка шаблона будет переложена на клиента.

Минус один - не каждый может/хочет его осилить.

 

[vaad2]

1. если говорить о простых шаблонизаторах - не так уж много надо усилий чтобы реализовать на указанных языках, а перегонять данные в xml и обратно не есть гут, если конечно используем БД. Мне в этом плане ближе json. И декодируется шустро, и на клиенте нормально работать, и просто удобней работать с массивом(объектом),
чем с DOM.
2. так и самописный можно также повесить
3. ну пока поисковики обращают внимание на теги и не юзают xsl (хотя кто их знает может и юзают), но сайтов немного видел где полагаются на клиентскую обработку xsl. И второе - это же просто находка для "грабителей", не надо ничего парсить - у тебя на блюдечке xml и пример его использования ))


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

Даже если брать в пример web сервисы, я еще помню времена как все писали от SOAP, в итоге в большинстве сервисов остался REST, JSON, и собственная реализация XML протокола.

 

[PHP_Master]

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

Немного надо усилий если в шаблоне файлов мизер, а если файлов до фигушки и одновременно используются PHP/Perl/Python, то это головная боль.

а перегонять данные в xml и обратно не есть гут, если конечно используем БД. Мне в этом плане ближе json. И декодируется шустро, и на клиенте нормально работать, и просто удобней работать с массивом(объектом),
чем с DOM.

Это дело привычки и навыков. Хотя я и сам люблю JSON.

2. так и самописный можно также повесить

Так самописный нужно ещё написать.

3. ну пока поисковики обращают внимание на теги и не юзают xsl (хотя кто их знает может и юзают), но сайтов немного видел где полагаются на клиентскую обработку xsl.

Я писал о том, что всё к этому идёт, а не то что это есть уже сейчас (то что есть сейчас малопригодно для использования).

И второе - это же просто находка для "грабителей", не надо ничего парсить - у тебя на блюдечке xml и пример его использования ))

Кому надо, те и так парсят с готового HTML. Ну заменится парсинг на разбор XML - итог один и тот же. В чём проблема?

Даже если брать в пример web сервисы, я еще помню времена как все писали от SOAP, в итоге в большинстве сервисов остался REST, JSON, и собственная реализация XML протокола.

Это вообще не понятно каким боком относится к теме.

 

[vaad2]

ну скажем не совсем тривиальная задача все указанное использовать сразу, если это веб-сервисы которые отдают xml, то тут вопросов нет, xsl в самую тему.

Кому надо, те и так парсят с готового HTML.

Кому надо, те и шаблонизатор свой повесят на сервер.

Это вообще не понятно каким боком относится к теме

к тому что XML предлагали как самую что ни наесть универсальную вещь для веб сервисов, SOAP как унив. протокол, в итоге коммунизьм не наступил, используют что удобней и эффективней, SOAP вообще редко видел чтобы применяли.... тоже самое и xsl - универсальный шаблонизатор может из него и хорош, но использовать его имеет смысл ориентируясь на задачи, а не потому что модно.

 

[winews]

мда... размышления заставляют задуматься о шаблонизаторе и стоит ли его вообще использовать если уж определенностив них нет, да и в выборе как таковом

 

[PHP_Master]

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

SOAP достаточно распространён на западе.
А так как к нам всё приходит с запада и с задержкой, бум использования SOAP до нас не дошёл.
Да и сам я его не люблю и для сервисов в основном использую JSON.
Но в данном топике речь ведётся о шаблонизаторах, а не контейнерах данных, так что сервисы и их реализации не совсем в тему.

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

С этим не поспоришь.
Наврядли стоит использовать XSLT для хомяка.

размышления заставляют задуматься о шаблонизаторе и стоит ли его вообще использовать если уж определенностив них нет, да и в выборе как таковом

Не в ту сторону думаешь.
Использовать стоит, а богатство выбора - это преимущество, а не недостаток.

 

[afonya09]

Попробуй шаблонизатог Гекон маленький и очень быстрый.