Околонаучные рассуждения о пользе и вреде шаблонных движков (вроде не флейм)

[Demiurg]

>но это скорее вопрос дисциплины при программировании
ну любой инструмент можно испортить

>хотя бы для простого написания/использования какой-нибудь украшательной функции
не понимаю, что именно за функции ? смарти может вызывать любые phpшные функции

 

[Дмитрий Попов]

svetasmirnova

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

Вы читали мой первый пост. Вы поняли, что я там писАл? Где я брал за аксиому указанную Вами фразу? Или я так паршиво выражаюсь, что меня понимают с точностью наоборот?
Я наоборот, утверждал, утверждаю и буду утверждать, что отделение логики и представления - это всего лишь возможное следствие использование шаблонизатора. Но не всегда - это причина, и тем более не всегда - цель.

 

[Кром]

>они не могут понять, что технологий и архитектурных решений существует бесчисленное множество

>И то, что при Вашем подходе - возможности Smarty излишни отнюдь не означает, что стиль программирования и проектирования другого разработчика, наоборот полнолстью соответствует необходимости использовать smarty.

>И вообще - я не зря упомянул про MVC, который Вы то ли проигнорировали, то ли вообще не знаете. Там вообще, шаблонизатор, можно сказать - ядро системы, а шаблон - вся логика вывода информации.

Насколько я понимаю, проблема Smarty именно в недостататке mvc шаблона, т.е. сложности отделения view от controller. В результате они пошли по принципу pull-шаблонов, что только углубило проблему, перемешав все и вся.
Так что на данный момент существующий стиль Smarty это не архитектурное решение задачи, а архитектурное решение проблемы.


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

У меня стойкое ощущение что Вы путаете причины и следствия. Или я Вас тоже понимаю с точность до наоборот?

 

[Demiurg]

Кром
а в чем проблемы у смарти?

 

[svetasmirnova]

Дмитрий Попов
Ряд моментов меня смутил, в частности:
>И, к сожалению, использование PHP в чистом виде,
приведённый ранее
>MVC. Этот подход по определению требует наличие прослойки работающей с шаблонами.
и дальше с цитатами из Фаната и спектатора.

Плюс такое мнение частенько прослеживается и вводит в заблуждение. А Ваши реплики ситуацию прояснили: двигаемся дальше

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

Demiurg
>не понимаю, что именно за функции ? смарти может вызывать любые phpшные функции

Имеется в виду $smarty->register_function? А если программист умер и дизайнер хочет подключить PHP-код прямо из шаблона Ну может быть да: лишняя свобода. Но и без неё можно нарегистрировать функций к отображению отношения не имеющих и в шаблоне их вызывать.

 

[Кром]

>а в чем проблемы у смарти?

Вот в этом:
{foreach from=$custid item=curr_id}

Именно это я и имел ввиду когда писал:
>это не архитектурное решение задачи, а архитектурное решение проблемы.

 

[Demiurg]

svetasmirnova
можно без register_function, когда смарти не находит модификатор у себя, он вызывает phpшную функцию с таким именем. Таким образом можно вызвать любую функцию у которой больше нуля входных параметров.

 

[Дмитрий Попов]

Кром
В этот раз я неправильно выразился. И, в принципе не знаю, как сказать правильнее.

Скажем так: Есть две крайности - шаблоны и данные. Не важно - что за шаблоны XSL, или же простой php файл. Неважно что за данные - CSV, XML файл или Oracle,DB2, или же $_REQUEST.
Есть средство соединения данных и шаблонов.

Вот, что входит в это средство - это уже зависит от каждого. И здесь может, среди прочего быть xtpl, sablotron или smarty, в купе с другим кодом, или же быть сразу же плоская выборка и выдача в шаблон. И обязательное наличие такого средства абсолютно неозначает необходимость в самописном шаблонизаторе. Так же как не означает и отсутствие необходимости в нём. И именно от того, как работает эта прослойка и зависит - какие будут шаблоны, и как они будут работать.
?>

 

[Screjet]

Система может определить - выводить этот блок или не надо. Выводить мыло или форму для отправки мыла. Выводить пароль, или нет, т.к. он хранится в md5.

Обычная логика отображения.

Но! При этом я не исключаю возможности обратного подхода, когда шаблон просит "система, а дай как мне данные для чекбосов".

Вот это уже правильно. Компонент обычно определен в шаблоне, а данные могут назначаться для компонента, либо он сам их "вытягивает". То же самое и для блоков.

 

[svetasmirnova]

Demiurg
Ну вот: ещё проще оказалось отказаться от разделения отображения и логики. Возможно, есть шаблонизаторы, использование которых само по себе диктует 100% разделение, но обо всех этого точно нельзя сказать. Впрочем, пора прекращать флуд

 

[Дмитрий Попов]

Мдя... Хотел без флейма не получилось =).

Попробую подвести итог - не разжигая флейм.

И так. О чем шла речь. Я просто попытался показать в начале топика, что сам по себе спор о пользе или вреде самописных шаблонизаторов нелеп. Сейчас могу более точно определить причины:
1. Вообще сложно дать четкое определение - что такое шаблонный движок. Ведь PHP - сам по себе, по большому счету является таковым.
2. Существует бесчисленное множество подходов и решений, для которых могут требоваться совершенно разные возможности шаблонов.
3. Польза от конкретного шаблонного движка может рассматриваться только одновременно с архитектурой приложения которое его использует.

С этим все согласны?

 

[Нечто]

ИМХО: (также лишь рассуждения на тему)
- "разделение логики и представления (отображения)" - неточное, если не сказать бессмысленное, выражение;
- "шаблон" - общий расплывчатый термин для обозначения некой инструкции вывода, которая, как здесь уже заметили, в разных системах играет разную роль в зависимости от целей, сложности и пр.;
- верстальщик (дизайнер) - существо смышленое, способное к производству логических конструктов и знающее как минимум js;
- программист - существо подвластное приступам лени, любящее покалякать на тему различных паранаучных "парадигм" (эстетически, безусловно, приятных), редко сомневающееся в том, что сложные построения бывает просто модернизировать и способное переложить тривиальные логические задачи на верстальщика;

 

[asm]

IMHO:
Что хорошо использовать:
- самописные шаблоны на основе php - да (никто не скажет что php это плохо)
- smarty и т.д. нет (изобретение велосипеда)
- xslt - имеет право на использование если данные хранятся в xml.(возможен симбиоз с п.1)

- ЛЮБОЕ приложение можно спроектировать не затачивая его на шаблоны из п.2

 

[AlMaz]

Каждая архитектура имеет право на жизнь... Но коли человек выбрал определенную (например MVC), то он должен ей следовать, и, соответственно, использовать только те возможности шаблонизатора, которые удовлетворяют данной арзитектуре.

Пример: Smarty и MVC. Используя {php}...{/php}. register_function, использование произвольных функций языка php в условиях {if} где попало и не для нужд логики представления, противоречит, на мой взгляд, архитектуре MVC.

 

[Дмитрий Попов]

AlMaz
Вы это к чему? Просто, что бы что-то сказать? Или Вы где-то увидели обсуждение того, как нельзя работать с MVC в Smarty?

 

[Screjet]

- ЛЮБОЕ приложение можно спроектировать не затачивая его на шаблоны из п.2

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

 

[AlMaz]

Дмитрий Попов
А кто говорил, что нельзя работать?
Просто было вами сказано "Существует бесчисленное множество подходов и решений, для которых могут требоваться совершенно разные возможности шаблонов".
И я привел пример конструкций, бездумное использование которыx в Smarty, может вывести за пределы архитектуры MVC.

И я совершенно согласен с выводами, которые были Вами сделаны.

 

[svetasmirnova]

А вот интересный момент. Все выступавшие уверены, что MVC просто необходимо использовать. А так ли это? Имеют ли право на существование крупные приложения, не реализующие этот паттерн?

 

[Screjet]

svetasmirnova
на существование = да, на развитие = нет

 

[svetasmirnova]

Screjet
Почему? Приведу такой пример. Допустим, мы решили написать клон phpMyAdmin для какой-нибудь другой БД. Учитывая задачи подобного приложения, оно:
1. Должно быть максимально приближенным к данной БД, то есть удобным для выполнения самых изысканных запросов.
2. Не должно быть безопасным в том же смысле, что и обычный web-сайт: такие приложения априори запускаются в специфических условиях.

И вот что получается: web-интерфейс нашего приложения привязан к БД, то есть к данным. Какой в этом случае смысл разделять данные и представление? И не усложнит ли такое разделение дальнейшую поддержку?