Ещё раз о шаблонах

[@Seldon]

На самом деле спорно, библиотеки подключают для чего?
1) не писать велосипед
2) упростить жизнь с кешированием
3) не тратить время на отладку
4) упростить жизнь свои приемникам, ведь с известной библиотекой многие работали и быстро вольются в проект, а с вашим кодом — нет.

Опять же возникают следующие вопросы:
1) Если у вас такой простой сайтик — зачем вы его сами пишите, используйте любую cms (да и вообще писать обычные сайты визитки с нуля — помоему ужасно)
2) На крупном проекте, все вышеперечисленные преимущества критичны, писать свое и отлаживать просто нет времени, тем более ваша ошибка может дорого стоить.

Писать свой шаблонизатор имеет смысл тогда когда специфичность вашего проекта не позволяет использовать готовые, но поверьте над такими проектами работают люди умные и они сами все знают и напишут шаблонизатор именно тот который надо им )
А писать на каждый проект шаблонизатор, простите это…

[@sectus]

> Действительно, встраивая все тот же Smarty в весьма простой по функционалу сайт, разработчик попросту тратит время.

Бездоказательно.

[@Seldon]

Мне больше интересно зачем писать простой сайт, когда уже куча готового? Зачем делать сайт визитку, если есть сотни Cms ) Мне — не понятно.
Другое дело если у васболее менее интересный функционал, предполагается порядочная нагрузка, но все равно вы возьмете yii, kohana, symfony и так далее. И зачем тогда писать свои шаблонизаторы? ) когда большинство популярных подключается на раз два.

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

[@shmaltorhbooks]

в итоге мы будем иметь еще один велосипед, который неясно как работает, неясно какие имеет подводные камни и при попытке добавить новый функционал поведет себя несно как. чем это лучше того же смарти или твига в сайте-визитке или среднем проекте? задача шаблонизатора — уменьшить время на разработку/отладку view'а и инкапсулировать внешний вид. смарти прекрасно справляется со своей задачей. у смарти есть сообщество, он ставится одной командой из консоли, любой мало-мальски грамотный php-разработчик имел дело со смарти, смарти отлажен и его баги известны всем либо гуглятся за пару минут. вы же предлагаете уйти от всего этого в угоду вашему личному (и, как по мне, весьма спорному) мнению о том, что 10-20 типов страниц и смарти — это «бить мух молотком». возможно, я неправильно понял смысл статьи и у вашего варианта есть какие-то плюсы по сравнению со смарти — я с любопытством выслушаю подробности о них.

[@koan]

Статья для тех, кто не осилил что-то серьёзное и всё еще пользуется модифицированным классом из phpbb2 для написания велосипедов. Каюсь, когда-то давно пару раз сам так делал.

[@basilisk]

Действительно, встраивая все тот же Smarty в весьма простой по функционалу сайт, разработчик попросту тратит время.

Неа. Для разработчика, знакомого со Smarty, всунуть шаблонизатор в «простой по функционалу сайт» — дело 15 минут. Это гораздо быстрее, удобнее и масштабируемее, чем писать свои велосипеды.

[@basilisk]

Упс. Сорри, это не вам :)

[@Seldon]

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

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

[@chEbba]

День PHP-велосипедов на хабре. habrahabr.ru/post/141714/

[@DeMx]

По сути, именно такую структуру использую в своих проектах. Иногда нужно немного добавить функционала, что-то вроде body_before или body_after (после header или перед footer), но в целом один в один. :)

[@snager]

Хоть один единомышленник :-)

[@werdender]

$tmpl->assign('ID', $_GET['ID']);
$tmpl->render();

Зря вы так, учитывая что в assign происходит:

$this->_vars[$name] = $value;

а затем в render:

extract($this->_vars);

[@zim32]

Подключение смарти — 10 минут. Написание своего шаблонизатора… ну вы поняли

[@egorinsk]

Автор показывает полное незнание темы. Смарти уже лет 5 как устарел — зачем его упоминать? Он всегда был уродливым, тормозным и неудобным (а теперь у нас есть неудобный и уродливый Twig вместо него :) ). XSLT автор скромно прошел стороной (мог бы хоть недостатки описать). Zend_view не упомняул (хотя предложенные классы — упрощенная версия Zend_view). Про наследование шаблонов и макросы в шаблонах не рассказал. Про новые идеи типа HAML не упомянул.

Это статья о шаблонах? Это набор устаревших и неправильных занний. Код автора тоже плох. В его шаблонизаторе даже функции include нет. Также, почему имя шаблона передается в конструктор, а не в render()? Чем это объясняется? непродуманностью?

[@zim32]

XSLT в шаблонах это та ещё жесть