Извольте. Мы говорим о шаблонизаторе — о работе с представлением. Причем тут убийство системы? Шаблонизатор должен заниматься только представлением (пришли данные — смонтировал. ). Ничего удалять он вообще не должен. Ни данные, ни файлы… Не должно быть такого функционала в принципе.
Если шаблонизатор позволяет делать такие вещи — то это уже новый язык программирования, почти… =)
«Некоторые даже думают что шаблонизаторы созданы для дизайнеров/верстальщиков, а программисту они не нужны. Так вот, все это миф. Шаблонизатор это программа созданная для того, что бы сделать разделение логик удобнее, предоставляющая некоторые расширенные функции, но она никак не является камнем преткновения.»
На кой мне сдался шаблонизатор, контроль которого один фиг осуществлять мне? Подумайте над этим. Шаблонизаторы а-ля str_replace ЛИШАЮТ возможности ошибиться дизайнеру => мне не нужно его контроллировать. Гениально, правда? :)
На тему «Облегчают смену дизайна». А не пофиг ли, как меняется дизайн, если шаблон описан примерно так:
[template id=«user_panel»]
… некоторый HTML-код
[/template]
[template id=«user_login»]
… форма авторизации
[/template]
[template id=«right_panel»]
[user_block]
[/template]
1. шаблон не меняется. Тот же HTML-код, только вместо логики — обычные _ПОДХОДЯЩИЕ_ПО_СМЫСЛУ_ мета-указатели а-ля [user_block].
2. за эту работу отвечаю я. Если получится скидка 30 процентов — это мой косяк. Де-факто.
>>> «стимулируют писать меньше логики в шаблонах,»
Эм… а вот в моем примере выше — вообще логики нет.
>>> «решают задачи кеширования»
Не шаблонизатора это дело… А системы, как мне кажется. никто не помешает мне «собранный html» сохранить в папочке cache
>>> решают задачи безопасности и это еще не все
каким это образом шаблонизаторы решают проблемы безопасности? мы, кажется, разговариваем по-взрослому, а не про то, как написать 5 запросов sql. Да?
Говоря о том, что PHP-шаблонизатор, я говорю не только о его прошлом. Но и текущих возможностях. Как был он шаблонизатором — так и содержит _ДО_СИХ_ПОР_ все возможности, которые были в FI.
Ну, для начала, давайте так. Разработчики нифига не озлоблены :)
А теперь по теме. Давайте называть вещи своими именами.
PHP — шаблонизатор. Smarty -шаблонизатор, работающий на шаблонизаторе. Цель — неясна. Якобы, распутывание логики.
Вопрос по такому подходу.
Если вы выносите if-ы в отдельный шаблон — почему бы не выносить их и обрабатывать native? Бизнес-логику по-прежнему держать можно отдельно. В чем минус-то native? +)
Послушайте, не увиливайте. Я вам дал цитатку вашего-же примера разделения кода от логики. Тут идет расчет значений массива. Так? Это — бизнес логика, но никак не логика представления.
И все-равно стоите на своем: Quicky разделяет логику от представления… Я балдю, дорогая редакция :)
Если Вам неприятно обсуждать данный вопрос — вы так и скажите. А насчет шаблонизаторов — я обязательно пообщаюсь с вами ;)
Вы таки не ответили насчет {return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}.
Если это не бизнес-логика, тогда что это?
В предвкушении ответа даю цитату из вики (по данному определению, рассчеты попадают в понятие «бизнес-логика»):
… Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).
К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
developer, я следил за вашими постами. Вроде — человек не глупый… Но получается, что циклы и if-ы это не логика.
Да, откину претензии по if-aм (хотя, условно — делая скидку.). Но циклы-то?
Или, вот еще:
{return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}
Вы действительно УВЕРЕНЫ, что это хорошо? Это раз.
Во-вторых, синтаксис нифига не упрощается. Проще дизайнера пыху научить — эффект тот же. Отладка, думаю, просто офигеть как упрощается, когда вычисления могут быть в 2-х АБСОЛЮТНО разных структурах (код и представление).
Вообщем, не убедили, если честно.
Можете возразить: «Используйте только if. если это вам нравится». Да, но в таком случае применение какого-либо шаблонизатора, подобного этому (я не обижаю разработчика — я про идеологию подобных штуковин) отпадает напрочь.
Да, конечно. Ничего положительного не увидел. Да и смысл для шаблонизатора писать шаблонизатор?
Понятно, что можно написать что угодно. Вопрос в целесообразности.
Отделением логики от представления текущий вариант не занимается. Что тогда он делает, откровенно говоря? Шаблонизатор ради шаблонизатора? (
Если шаблонизатор позволяет делать такие вещи — то это уже новый язык программирования, почти… =)
Мы говорим о логике (и бизнес-логике и о логике разметки). Причем тут диверсия?
«Некоторые даже думают что шаблонизаторы созданы для дизайнеров/верстальщиков, а программисту они не нужны. Так вот, все это миф. Шаблонизатор это программа созданная для того, что бы сделать разделение логик удобнее, предоставляющая некоторые расширенные функции, но она никак не является камнем преткновения.»
На кой мне сдался шаблонизатор, контроль которого один фиг осуществлять мне? Подумайте над этим. Шаблонизаторы а-ля str_replace ЛИШАЮТ возможности ошибиться дизайнеру => мне не нужно его контроллировать. Гениально, правда? :)
На тему «Облегчают смену дизайна». А не пофиг ли, как меняется дизайн, если шаблон описан примерно так:
[template id=«user_panel»]
… некоторый HTML-код
[/template]
[template id=«user_login»]
… форма авторизации
[/template]
[template id=«right_panel»]
[user_block]
[/template]
1. шаблон не меняется. Тот же HTML-код, только вместо логики — обычные _ПОДХОДЯЩИЕ_ПО_СМЫСЛУ_ мета-указатели а-ля [user_block].
2. за эту работу отвечаю я. Если получится скидка 30 процентов — это мой косяк. Де-факто.
>>> «стимулируют писать меньше логики в шаблонах,»
Эм… а вот в моем примере выше — вообще логики нет.
>>> «решают задачи кеширования»
Не шаблонизатора это дело… А системы, как мне кажется. никто не помешает мне «собранный html» сохранить в папочке cache
>>> решают задачи безопасности и это еще не все
каким это образом шаблонизаторы решают проблемы безопасности? мы, кажется, разговариваем по-взрослому, а не про то, как написать 5 запросов sql. Да?
А теперь по теме. Давайте называть вещи своими именами.
PHP — шаблонизатор. Smarty -шаблонизатор, работающий на шаблонизаторе. Цель — неясна. Якобы, распутывание логики.
Вопрос по такому подходу.
Если вы выносите if-ы в отдельный шаблон — почему бы не выносить их и обрабатывать native? Бизнес-логику по-прежнему держать можно отдельно. В чем минус-то native? +)
И все-равно стоите на своем: Quicky разделяет логику от представления… Я балдю, дорогая редакция :)
Если Вам неприятно обсуждать данный вопрос — вы так и скажите. А насчет шаблонизаторов — я обязательно пообщаюсь с вами ;)
Если это не бизнес-логика, тогда что это?
В предвкушении ответа даю цитату из вики (по данному определению, рассчеты попадают в понятие «бизнес-логика»):
… Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).
К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
Да, откину претензии по if-aм (хотя, условно — делая скидку.). Но циклы-то?
Или, вот еще:
{return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}
Вы действительно УВЕРЕНЫ, что это хорошо? Это раз.
Во-вторых, синтаксис нифига не упрощается. Проще дизайнера пыху научить — эффект тот же. Отладка, думаю, просто офигеть как упрощается, когда вычисления могут быть в 2-х АБСОЛЮТНО разных структурах (код и представление).
Вообщем, не убедили, если честно.
Можете возразить: «Используйте только if. если это вам нравится». Да, но в таком случае применение какого-либо шаблонизатора, подобного этому (я не обижаю разработчика — я про идеологию подобных штуковин) отпадает напрочь.
Имхо, ессно =)
Понятно, что можно написать что угодно. Вопрос в целесообразности.
Отделением логики от представления текущий вариант не занимается. Что тогда он делает, откровенно говоря? Шаблонизатор ради шаблонизатора? (
Мне одному всегда хватало str_replace и {varname}?
2diablitozzz: думаю, xslt будет побыстрее. Ибо не нативным пыхом рулится.
Другое дело, если вы в странице отдаете стили и код JS. Так что много все-равно не выиграете.
ЗЫ. Говорите «свой svn», а приводите только фряху в качестве примера.
ЗЫЫ: в Debian ставится так:
aptitude install svn mod_dav
Дальше аптитуд рулит все зависимости. В файле конфигурации mod_dav конфигурируем web-доступ, делаем svnadmin create…
Вот реп и готов :=)