Comments 14
Напрашивается сравнительное тестирование уймы PHP-шаблонизаторов
Слова «сравнительное тестирование» для меня звучат зловеще. Если често, то я не уверен, что в сравнительных тестированиях есть толк, в смысле их полезности для кого-либо, кроме тестирующего.
Поясню:
Поэтому для себя я просто сравниваю. Без тестов.
Впрочем, мои тараканы, конечно же, ни к коей мере не мешают производителям шаблонизаторов, например, замерять скорость работы. А эти данные обычно имеются в открытом доступе на сайтах производителей.
Поясню:
- Во-первых, не ясно, кому какие критерии интересны.
- Во-вторых, не ясно на какой конфигурации проводить замеры. Ещё ни разу, ознакомившись с результатами тестов, я не смог прикинуть, как этот пациент будет вести себя на целевой конфигурации.
- Во-третьих, результаты тестирования будут отражать состояние вещей на текущий конкретный момент и уже завтра могут перестать соответствовать действительности.
Поэтому для себя я просто сравниваю. Без тестов.
Впрочем, мои тараканы, конечно же, ни к коей мере не мешают производителям шаблонизаторов, например, замерять скорость работы. А эти данные обычно имеются в открытом доступе на сайтах производителей.
Разрешите проявить взаимный академический интерес, не холивара ради:
Можно какой-то пример из жизни или что-то подобное?
Просто лично мне трудно представить себе конфигурацию, когда данные проблемы может хоть немного помочь решить шаблонизатор.
Мне всегда казалось, что он этих проблем добавляет, однако я могу ошибаться.
жизненно необходимо для поддержвания качественных и количественных показателей работы
Можно какой-то пример из жизни или что-то подобное?
Просто лично мне трудно представить себе конфигурацию, когда данные проблемы может хоть немного помочь решить шаблонизатор.
Мне всегда казалось, что он этих проблем добавляет, однако я могу ошибаться.
Не понял, конфигурацию чего вы имеете в виду, но в качестве запрошенного примера могу предложить описания из разделов статьи «Синтаксис» и «Безопасность», то есть это опять-таки разговор о количестве логики, которую можно вынести в шаблоны — об уровнях абстакции. Если для вас дополнительный слой логики обоснованно избыточен — не нужно его использовать. Проводя аналогию: ООП — это тоже слой абстракции, без которого люди успешно обходятся и будут обходиться.
О примерах: если поручить работу над шаблонами лицу, не связанному с программированием [не знакомому с PHP], это лицо быстрее выучивает ограниченный набор команд шаблонизатора. Видимо, потому, что объем материала меньше. У этого лица не будет возможности вмешатся в функционирование основного потока приложения и, возможно нечаянно, но с большой вероятностью озадачить разработчиков поиском ошибки в своём коде. Если шаблоны поддерживают программисты, то им часто шаблонизатор диктует держаться в рамках: замечено, что при использовании шаблонизатора чаще задумываешься о том, стоит ли ту или иную часть логики реализовывать в шаблоне.
Повторюсь: всё описанное, конечно, возможно и без применения шаблонизаторов, просто требует большего количества усилий, например, организаторских.
И на всякий случай поясню, что «жизненно» из цитаты относится к успешности существования проекта, а не его участников %)
О примерах: если поручить работу над шаблонами лицу, не связанному с программированием [не знакомому с PHP], это лицо быстрее выучивает ограниченный набор команд шаблонизатора. Видимо, потому, что объем материала меньше. У этого лица не будет возможности вмешатся в функционирование основного потока приложения и, возможно нечаянно, но с большой вероятностью озадачить разработчиков поиском ошибки в своём коде. Если шаблоны поддерживают программисты, то им часто шаблонизатор диктует держаться в рамках: замечено, что при использовании шаблонизатора чаще задумываешься о том, стоит ли ту или иную часть логики реализовывать в шаблоне.
Повторюсь: всё описанное, конечно, возможно и без применения шаблонизаторов, просто требует большего количества усилий, например, организаторских.
И на всякий случай поясню, что «жизненно» из цитаты относится к успешности существования проекта, а не его участников %)
> если поручить работу над шаблонами лицу, не связанному с программированием
я вот по этой причине когда-то использовал tal — он добавляет xml-атрибуты к тегам, это гораздо удобнее верстальщикам(даже wysiwig-редакторы такие шаблоны не ломают)
я вот по этой причине когда-то использовал tal — он добавляет xml-атрибуты к тегам, это гораздо удобнее верстальщикам(даже wysiwig-редакторы такие шаблоны не ломают)
> Не понял, конфигурацию чего вы имеете в виду
Описание ситуации где без шаблонизатора будут проблемы. Кто, где, что, когда и т.д.
Я просто давно слежу за разными реальными случаями из жизни из жизни разработчиков+шаблонов и
у меня собрался ворох наблюдений.
Относительно Синтаксиса:
Все говорят про какой-то абстрактный порог вхождения. Вот честное слово, такое чувство будто человек который будет заниматься версткой это медицинский дебил. Просто если это так, то зачем ему вообще поручать заниматься версткой?
Давайте уже не кривя душей скажем, что 95% кодинга верстальщика покрывается в этих командах (Smarty):
Не совсем понимаю, где тут порог вхождения проще.
Он вообще одинаковый.
Просто вот лично я не видел ни разу чтобы шаблоны имели хоть какое-то реально положительное влияние на проект.
Описание ситуации где без шаблонизатора будут проблемы. Кто, где, что, когда и т.д.
Я просто давно слежу за разными реальными случаями из жизни из жизни разработчиков+шаблонов и
у меня собрался ворох наблюдений.
Относительно Синтаксиса:
Все говорят про какой-то абстрактный порог вхождения. Вот честное слово, такое чувство будто человек который будет заниматься версткой это медицинский дебил. Просто если это так, то зачем ему вообще поручать заниматься версткой?
Давайте уже не кривя душей скажем, что 95% кодинга верстальщика покрывается в этих командах (Smarty):
<?=$foo?>
{$foo}
<?=$foo['bar']?>
{$foo.bar}
<?php foreach($foo as $bar){ ?> a <?php } ?>
{foreach $foo as $bar}a{/foreach}
<?php if($foo=='Fred '){ ?> yes<?php }else{ ?> no<?php } ?>
{if $name == 'Fred' '} yes{/if}{else} no {/else}
<?php include('page_header.tpl');?>
{include file='page_header.tpl'}
Не совсем понимаю, где тут порог вхождения проще.
Он вообще одинаковый.
Просто вот лично я не видел ни разу чтобы шаблоны имели хоть какое-то реально положительное влияние на проект.
Все говорят про какой-то абстрактный порог вхождения.
Не скажу за всех, но в целом всё верно: порог вхожения — понятие абстрактное и по-иному быть не может, ибо для каждого этот порог свой.
Вот честное слово, такое чувство будто человек который будет заниматься версткой это медицинский дебил.
Странное чувство. Непонятно, откуда оно у вас. Речь шла о том, что людям, занимающимся дизайном/вёрсткой должно быть не досуг думать о том, как, например, обратиться к атрибуту сущности (вне зависимости от того, массив это, скажем, или объект), как обработать ошибку доступа к методу объекта, и в том же духе, — им бы вместо этого свою работу выполнять и другим проблем не создавать.
Давайте уже не кривя душей скажем, что 95% кодинга [...]
Возможно покрываются, возможно нет. Никогда не интересовался этим процентом.
Просто вот лично я не видел ни разу чтобы шаблоны имели хоть какое-то реально положительное влияние на проект.
Ну, я тоже, к примеру, не видел, чтобы поклонение шаблонам проектирования имело какое-то реально положительное влияние на проект, а некоторые божатся, что такое имеет место быть %)
а почему не jinja был взят за основу? синтаксис почти такой же, а гвоздями не прибит и django и быстрее.
p.s. забавно, когда-то, когда писал на php использовал шаблоны tal, а это тоже порт с zope
p.s. забавно, когда-то, когда писал на php использовал шаблоны tal, а это тоже порт с zope
Джинжу Армин срисовывал с Джанго, не удивительно, что синтаксис «почти такой же».
Портировать Джинжу полноценно не получилось бы в любом случае: Армин пытался, но понял тщетность затеи. Потом, правда, идею подхватил Фабьен в своём Твиге, адаптировав под реалии PHP — и со скоростью у него всё в порядке вышло, да только в области расширения случился прокол — слишком накладно писать свои теги.
Скорее закономерно: идеи кочуют. Хорошо, когда это хорошие идеи %)
Портировать Джинжу полноценно не получилось бы в любом случае: Армин пытался, но понял тщетность затеи. Потом, правда, идею подхватил Фабьен в своём Твиге, адаптировав под реалии PHP — и со скоростью у него всё в порядке вышло, да только в области расширения случился прокол — слишком накладно писать свои теги.
забавно, когда-то, когда писал на php
Скорее закономерно: идеи кочуют. Хорошо, когда это хорошие идеи %)
> идеи кочуют
кстати, в современных версиях php с этим стало проще. те же замыкания/анонимные функции очень помогают.
p.s. когда-то писал конвертер python->php для ограниченного подмножества python. github.com/idlesign/dja/blob/master/dja/dja_pyhelpers.php — ох как бы мне пригодилось тогда:) но и сам python выручал — начиная от модулей типа lex до разбора ast
кстати, в современных версиях php с этим стало проще. те же замыкания/анонимные функции очень помогают.
p.s. когда-то писал конвертер python->php для ограниченного подмножества python. github.com/idlesign/dja/blob/master/dja/dja_pyhelpers.php — ох как бы мне пригодилось тогда:) но и сам python выручал — начиная от модулей типа lex до разбора ast
кстати а у php есть байткод сейчас или это классический интерпретатор? я вот сейчас подумал что можно было бы пойти более низким уровнем.
да только в области расширения случился прокол — слишком накладно писать свои теги.
Вы что-то путаете, расширение Twig предельно простое занятие — свой тег можно за 5 минут написать.
Sign up to leave a comment.
Шаблоны в шаблонизаторе и как шаблоны Django до PHP дошли (в очередной раз)