С.
Продвинутый новичок
Ну действительно, запрос к базе данных в шаблоне - это ad absurdum. Однако частенько бывает, что надо провести какие-то вычесления или расчеты, связанные исключительно с отображением данных, а не логикой проекта. Спрашивается куда этот блок кода помещать, в шаблон или в вычислительный модуль?
С третье-сторонними шаблонами вопрос сам собой решается - они либо не могут ничего вычислять, либо жеманно позволяют вставлять тот же PHP код в себя, а это еще уродливей получается. В таком случае уж лучше это вынести в вычислительный блок. Однако тогда получается загромождение алгоритма вещами, к нему не относящимися.
В другом варианте надо либо развивать шаблон, либо не тянуть кота за хвости и просто в качестве шаблонного языка использовать сам PHP. А после этого и следующий шаг напрашивается: если и там и там PHP, то зачем парсить два раза, если можно один?
Вообще единственной причиной появления Smarty-подобных шаблонов было якобы простота их использования дизайнерами-непрограммистами. Однако к чему он пришел? Оказалось, что приходится кешировать код, приходится разрешать делать вставки на другом языке и прочие усложнения, которые сводят на нет саму главную причину своего появления. Самодостаточный шаблонный язык становится таким же сложным, как обычный язык программирования. Кстати есть один такой язык, который прошел именно этим путем развития - из языка шаблонов стал полноценным программным. Догадаетесь какой?
И еще: образ дизайнера-непрограммиста это как старшилка про лешего. Сказок про него много, но никто его не видел. При современных технологиях и требованиях к дизайну, когда приходится работать и с ява-скриптом, и с флешем, который и сам скриптоподобен, плюс имет свой собственный скрипт, говорить про дизайнера-непрограммиста уже смешно. Пусть это будет не один человек, а дизайн-группа, сотоящая из чисто художника и чисто программиста, но суть от этого не меняется: визуализатор обязан уметь работать со сложными шаблонами.
С третье-сторонними шаблонами вопрос сам собой решается - они либо не могут ничего вычислять, либо жеманно позволяют вставлять тот же PHP код в себя, а это еще уродливей получается. В таком случае уж лучше это вынести в вычислительный блок. Однако тогда получается загромождение алгоритма вещами, к нему не относящимися.
В другом варианте надо либо развивать шаблон, либо не тянуть кота за хвости и просто в качестве шаблонного языка использовать сам PHP. А после этого и следующий шаг напрашивается: если и там и там PHP, то зачем парсить два раза, если можно один?
Вообще единственной причиной появления Smarty-подобных шаблонов было якобы простота их использования дизайнерами-непрограммистами. Однако к чему он пришел? Оказалось, что приходится кешировать код, приходится разрешать делать вставки на другом языке и прочие усложнения, которые сводят на нет саму главную причину своего появления. Самодостаточный шаблонный язык становится таким же сложным, как обычный язык программирования. Кстати есть один такой язык, который прошел именно этим путем развития - из языка шаблонов стал полноценным программным. Догадаетесь какой?
И еще: образ дизайнера-непрограммиста это как старшилка про лешего. Сказок про него много, но никто его не видел. При современных технологиях и требованиях к дизайну, когда приходится работать и с ява-скриптом, и с флешем, который и сам скриптоподобен, плюс имет свой собственный скрипт, говорить про дизайнера-непрограммиста уже смешно. Пусть это будет не один человек, а дизайн-группа, сотоящая из чисто художника и чисто программиста, но суть от этого не меняется: визуализатор обязан уметь работать со сложными шаблонами.