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

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

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

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

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

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

$tpl->printToScreen();
а в html шаблоне все примерно так:
HTML:
<!-- START BLOCK : title -->
{error_text}
<!-- END BLOCK : title -->
 
XSLT - фу в степени, ездили знаем.
Смысл XSD валидации и т.п. если нормально нельзя отобразить ошибку пользователю - что, конкретно, и на нужном языке, хотя может с тех пор прогресс шагнул дальше, но раньше были невнятные сообщения на англ. языке. Т.е. делаешь 2-ю работу отвалидировал, и если че не так еще должен сам сказать в каком элементе фу...
Я не говорю о том что xml не есть стандартный протокол, т.е. это надо считывать данные преобразовывать в валидный xml вид и конвертить xslем.

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

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

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

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


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

Даже если брать в пример web сервисы, я еще помню времена как все писали от SOAP, в итоге в большинстве сервисов остался REST, JSON, и собственная реализация XML протокола.
 
если говорить о простых шаблонизаторах - не так уж много надо усилий чтобы реализовать на указанных языках
Немного надо усилий если в шаблоне файлов мизер, а если файлов до фигушки и одновременно используются PHP/Perl/Python, то это головная боль.
а перегонять данные в xml и обратно не есть гут, если конечно используем БД. Мне в этом плане ближе json. И декодируется шустро, и на клиенте нормально работать, и просто удобней работать с массивом(объектом),
чем с DOM.
Это дело привычки и навыков. Хотя я и сам люблю JSON.
2. так и самописный можно также повесить
Так самописный нужно ещё написать.
3. ну пока поисковики обращают внимание на теги и не юзают xsl (хотя кто их знает может и юзают), но сайтов немного видел где полагаются на клиентскую обработку xsl.
Я писал о том, что всё к этому идёт, а не то что это есть уже сейчас (то что есть сейчас малопригодно для использования).
И второе - это же просто находка для "грабителей", не надо ничего парсить - у тебя на блюдечке xml и пример его использования ))
Кому надо, те и так парсят с готового HTML. Ну заменится парсинг на разбор XML - итог один и тот же. В чём проблема?
Даже если брать в пример web сервисы, я еще помню времена как все писали от SOAP, в итоге в большинстве сервисов остался REST, JSON, и собственная реализация XML протокола.
Это вообще не понятно каким боком относится к теме.
 
ну скажем не совсем тривиальная задача все указанное использовать сразу, если это веб-сервисы которые отдают xml, то тут вопросов нет, xsl в самую тему.

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

Это вообще не понятно каким боком относится к теме
к тому что XML предлагали как самую что ни наесть универсальную вещь для веб сервисов, SOAP как унив. протокол, в итоге коммунизьм не наступил, используют что удобней и эффективней, SOAP вообще редко видел чтобы применяли.... тоже самое и xsl - универсальный шаблонизатор может из него и хорош, но использовать его имеет смысл ориентируясь на задачи, а не потому что модно.
 
мда... размышления заставляют задуматься о шаблонизаторе и стоит ли его вообще использовать если уж определенностив них нет, да и в выборе как таковом
 
к тому что XML предлагали как самую что ни наесть универсальную вещь для веб сервисов, SOAP как унив. протокол, в итоге коммунизьм не наступил, используют что удобней и эффективней, SOAP вообще редко видел чтобы применяли....
SOAP достаточно распространён на западе.
А так как к нам всё приходит с запада и с задержкой, бум использования SOAP до нас не дошёл.
Да и сам я его не люблю и для сервисов в основном использую JSON.
Но в данном топике речь ведётся о шаблонизаторах, а не контейнерах данных, так что сервисы и их реализации не совсем в тему.
тоже самое и xsl - универсальный шаблонизатор может из него и хорош, но использовать его имеет смысл ориентируясь на задачи, а не потому что модно.
С этим не поспоришь.
Наврядли стоит использовать XSLT для хомяка.
размышления заставляют задуматься о шаблонизаторе и стоит ли его вообще использовать если уж определенностив них нет, да и в выборе как таковом
Не в ту сторону думаешь.
Использовать стоит, а богатство выбора - это преимущество, а не недостаток.
 
Попробуй шаблонизатог Гекон маленький и очень быстрый.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху