LINUX.ORG.RU

php и smarty

 ,


0

1

Скажу сразу, я любитель и пишу для себя. ;))) Так вот, поставил новый сервер, php 8.2.24 и smarty 5.4.1 и не могу заставить работать, последний раз ставил 3.х, навастривал аналогично. архив распаковал в /var/www/html/inc/smarty

index.php

require_once('inc/smarty/libs/Smarty.class.php');

$smarty = new Smarty();

$smarty->setTemplateDir('templates/');
$smarty->setCompileDir('templates_c/');
$smarty->caching = false;

$smarty->assign('name', 'Test);
$smarty->display('index.tpl');

Подскажите куда капать?

Ответ на: комментарий от cobold

А чем он тебе так не угодил?

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

firkax ★★★★★
()
Ответ на: комментарий от cobold

Чтобы не тащить никакого мусора - шаблонизатор должен быть в виде php extension на си. А те что на пхп написаны все одинаково неоптимальные. То же самое касается и фреймворков и любителей графоманить простыни кода на пхп в качестве их.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

asdf/phpenv помогут отцу русскорй демократии, поставить нужную версию похапе, которая дружит с калом мамонта типа смарти. Но я бы посоветовал его не использовать, так как идея шаблонизатора на шаблонизаторе заведома придурочная, тем более профессии верстальщика больше не существует и нет нужды в ограничении последних в возможности нагадить

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от Obezyan

Эм...

1) «Уже есть» - это и к smarty относится

2) Писать свой - чтоб не возиться с чужой графоманией

3) Судя по тому что он в домене .symfony. - лучше к нему не приближаться

4) Учитывая что они оба конвертят шаблоны в пхп-код, сомневаюсь что там может быть какая-то существенная разница в скорости

firkax ★★★★★
()
Ответ на: комментарий от firkax
  1. «Уже есть» - это и к smarty относится

Я имел ввиду он создавался как замена и smarty и встроенному в php шаблонизатору.

  1. Писать свой - чтоб не возиться с чужой графоманией

В рамках пет-проекта это еще имеет смысл, но не более того. Вы не напишите свой вариант лучше чем twig при этом потратите кучу времени.

  1. Судя по тому что он в домене .symfony. - лучше к нему не приближаться

Боритесь с предрассудками. Судить о пакете исключительно по домену верхнего уровня тоже самое что судить о человеке по цвету кожи.

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

Сомневаетесь - погуглите тесты или проведите свои. Я делал и то и другое.

Obezyan
()
Ответ на: комментарий от Obezyan

Я имел ввиду он создавался как замена и smarty и встроенному в php шаблонизатору.

Я тоже могу награфоманить «замену» чему угодно, это не повод его сувать сразу везде.

Вы не напишите свой вариант лучше чем twig при этом потратите кучу времени.

Напишу, разумеется. Чтобы сделать лучше чем twig особо и стараться не надо.

Боритесь с предрассудками. Судить о пакете исключительно по домену верхнего уровня тоже самое что судить о человеке по цвету кожи.

Дело не в домене, а в том что симфони пишут индусы-графоманы, а раз это их подпроект значит качество аналогичное.

Сомневаетесь - погуглите тесты или проведите свои. Я делал и то и другое.

Поздравляю, а я лучше просто не буду тащить к себе всякую блоатварь.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Я тоже могу награфоманить «замену» чему угодно, это не повод его сувать сразу везде.

Громкое заявление, проверять мы его конечно не будем.

Напишу, разумеется. Чтобы сделать лучше чем twig особо и стараться не надо.

Нет, не напишите. Не врите себе (и нам). Вы не осилите в одиночку написать также или лучше. Хотите опровергнуть мое утверждение? Хорошо - давайте, пишите, потом покажете, только код не используйте чужой, а пишите свой. А я как системный архитектор потом проведу аудит :)

Дело не в домене, а в том что симфони пишут индусы-графоманы, а раз это их подпроект значит качество аналогичное.

Ваши знания слишком поверхностны чтобы делать такие выводы. Twig (PHP шаблонизатор) создал автор Flask (Python фреймворк) на базе Jinja (Python шаблонизатор), поле чего продолжил развивать автор Symfony (PHP фреймворк), поэтому twig используется в symfony по-умолчанию и имеет такой домен. А все ваши рассуждения об индусах - мимо, они на пару уровней ниже.

Obezyan
()
Ответ на: комментарий от Obezyan

У нас видимо имеется расхождение в понимании того что такое хороший шаблонизатор. И вообще что такое хороший код.

Огромные простыни вложенных функций на 10+ уровней - это плохо, скриптовый код должен быть коротким и небольшого уровня вложения. Вся низкоуровневая логика общего назначения должна быть на компилируемом языке и подключаться в виде extension-ов. А сам пхп - это клей чтоб из этих компонентов сделать высокоуровневый продукт + чуть чуть снабдив его «бизнес-логикой».

А так то да, давайте ещё mysql-клиент на пхп перепишем для создания впечатления серьёзности.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Огромные простыни вложенных функций на 10+ уровней - это плохо,

не понял о какие 10+ уровней вложений идет речь. Обычно, при грамотно организованых шаблонах даже вложенных циклов обычно нет, максимум один цикл. Помимо это есть кеш, те шаблонизатор не работает на каждый запрос, большую часть времени он возвращает из кеша.

Вся низкоуровневая логика общего назначения должна быть на компилируемом языке и подключаться в виде extension-ов.

Низкоуровневая - да. Бизнес логика - нет. Шаблонизация не является бизнес-логикой, но очень сильно на нее завязана, настолько сильно, что управление этой самой шаблонизацией располагается рядом с бизнес логикой, а не в отдельных скомпилированных расширениях.

А сам пхп - это клей чтоб из этих компонентов сделать высокоуровневый продукт + чуть чуть снабдив его «бизнес-логикой».

Не чуть-чуть, а вся, буквально вся бизнес логика там.

Obezyan
()
Ответ на: комментарий от Obezyan

не понял о какие 10+ уровней вложений идет речь.

Поймай стектрейс из твига, увидишь.

Шаблонизация не является бизнес-логикой, но очень сильно на нее завязана,

Нет, не завязана. Шаблоны завязаны, шаблонизатор - нет.

Не чуть-чуть, а вся, буквально вся бизнес логика там.

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

Поймай стектрейс из твига, увидишь.

Для этого нужно отключить кеш. А зачем? Вы пытаетесь оптимизизировать то что уже оптимизировано кешем.

Нет, не завязана. Шаблоны завязаны, шаблонизатор - нет.

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

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

Откройте код бизнес объектов, например, Magento 2. Там почти нечего убирать в компилируемые расширения. А перенос одной EAV системы займет пару лет. В итоге, это все неоправданно по усилиям и времени.

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

Obezyan
()
Ответ на: комментарий от Obezyan

Вы пытаетесь оптимизизировать то что уже оптимизировано кешем.

Нет, я про то что от помойки надо избавляться, а не накрывать её покрывалом.

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

Чего «этого»? Что ты несёшь? Шаблонизатор это не управление шаблонами, а генерация html по входным данным, которые включают в себя название шаблона и массив с аргументами к нему.

Откройте код бизнес объектов, например, Magento 2. Там почти нечего убирать в компилируемые расширения.

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

приходится оптимизировать вусмерть то что есть. Я не занимаюсь таким.

Не «оптимизировать вусмерть», а соблюдать элементарную культуру разработки. Пхпшникам она часто неведома, а элементарные действия они считают чем-то запредельно сложным.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Magento 2 это действительно дефективная архитектура. Я просто пример пример того на чем сидит половина средних и больших магазинов за рубежом.

Наше отличие в том что я не сторонник подхода оптимизации ради оптимизации.

Obezyan
()