Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 148
Интересно было бы провести голосование «за» и «против» :)
а что тут дискутировать? шаблонизаторы нужны там, где нужна четкая структура представления данных, при этом вопрос о скорости приложений — не самый главный. пример — внутренняя система компании, где могут быть тысячи файлов кода и нужна четкая структура, для того, чтобы в этом не запутаться. шаблонизаторы нужны именно для того, чтобы отделить представление от выполнения рассчетов.
если вы уверерены, что вы и ваша комманда 100% не будет мешать эти два составляющих используя php для шаблонов, то шаблонизаторы и не нужны. шаблонизатор — это не красивое дополнение к проекту, а функциональная составляющая, и она занимает по важности такое же место, как, например тип хранилища данных. Т.е. спор «нужен шаблонизатор или нет?» это выглядит также как «использовать MySQL или текстовые файлы?». Решаемо для каждого случая в частности в общем.
если вы уверерены, что вы и ваша комманда 100% не будет мешать эти два составляющих используя php для шаблонов, то шаблонизаторы и не нужны. шаблонизатор — это не красивое дополнение к проекту, а функциональная составляющая, и она занимает по важности такое же место, как, например тип хранилища данных. Т.е. спор «нужен шаблонизатор или нет?» это выглядит также как «использовать MySQL или текстовые файлы?». Решаемо для каждого случая в частности в общем.
Спасибо за приглашение :)
Итак:
СМАРТИ-подобные шаблонизаторы не могут полноценно разделить логику представления от бизнес-логики. Есть вероятность, что шаблон будет влезать в бизнес-логику. Это большой минус. И именно поэтому я не пользуюсь шаблонизаторами такого типа.
Что есть шаблон в нашем контексте? Шаблон — это разметка страницы, в которую подставляются данные, сгенерированные бизнес-логикой.
Если мы используем смарти-шаблонизатор, то появляется возможность изменять переданные бизнес-логикой данные перед выдачей. А это не всегда приемлемо.
Итак:
СМАРТИ-подобные шаблонизаторы не могут полноценно разделить логику представления от бизнес-логики. Есть вероятность, что шаблон будет влезать в бизнес-логику. Это большой минус. И именно поэтому я не пользуюсь шаблонизаторами такого типа.
Что есть шаблон в нашем контексте? Шаблон — это разметка страницы, в которую подставляются данные, сгенерированные бизнес-логикой.
Если мы используем смарти-шаблонизатор, то появляется возможность изменять переданные бизнес-логикой данные перед выдачей. А это не всегда приемлемо.
Пример: верстальщик запросто может «сделать скидку» для всех товаров в магазине в размере 30%
Вы сами выбираете для себя степень ответственности перед вашими коллегами — это цена за невероятную гибкость
конечно, с хорошим инструментом каждый лох может думать что он БОГ, но ответственность разграничена, человек сделал это в представлении, он верстальщик и это не входит в зону его ответственности, значит он виноват и из-за того что система расслоена на зоны ответственности его вина доказывается
конечно, с хорошим инструментом каждый лох может думать что он БОГ, но ответственность разграничена, человек сделал это в представлении, он верстальщик и это не входит в зону его ответственности, значит он виноват и из-за того что система расслоена на зоны ответственности его вина доказывается
Означает ли это, что вы признаете, что смарти-шаблонизаторы смешивают логику и представление?
сами они не смешивают, а позволяют разделять, но если вы хотите неверно трактовать рекомендации, то вы сможете смешать, но ваше деяние станет явным, и вас можно будет наказать =)
ну само собой они не смешивают сами… Это делают программист+верстальщик, который ими пользуется. А минус смарти-шаблонизаторов в том, что они позволяют это делать.
А хз кстати кто эту скидку сделал. Если нет системы контроля версий, то фиг поймешь, кто эту правку внес: программист или верстальщик.
Итак, надеюсь, консенсус достигнут: квики и смарти позволяют смешивать бизнес-логику и представление. Минусы видны из примера. Каждый сам принимает решение, критично для него это или нет.
А хз кстати кто эту скидку сделал. Если нет системы контроля версий, то фиг поймешь, кто эту правку внес: программист или верстальщик.
Итак, надеюсь, консенсус достигнут: квики и смарти позволяют смешивать бизнес-логику и представление. Минусы видны из примера. Каждый сам принимает решение, критично для него это или нет.
скажем так: это следствие недостаточной интеллектуальности компьютеров вообще.
Это не минус квики, это не абсолютная победа в данном вопросе. Да он помогает вам смешивать меньше, но не может вас заставить это сделать.
Это не минус квики, это не абсолютная победа в данном вопросе. Да он помогает вам смешивать меньше, но не может вас заставить это сделать.
А я знаю (и пользуюсь ими) шаблонизаторы, которые не позволяют это делать :)
{VAR} и < !-- BEGIN -->...<! — END -->
Вобщем, как обычно, пришли к выводу: шурупам — отвертки, гвоздям — молотки. Хотя молотки универсальнее ;)
{VAR} и < !-- BEGIN -->...<! — END -->
Вобщем, как обычно, пришли к выводу: шурупам — отвертки, гвоздям — молотки. Хотя молотки универсальнее ;)
так первая ветка тезисов-камней в сад шаблонизаторов есть:
квики и смартиобразные шаблонизаторы не запрещают смешивать бизнес-логику и представление, хотя стараются и спрепятствуют этому смешанию.
{VAR} и < !-- BEGIN -->...<! — END --> запрещает же на корню.
но в замен в этом месте шаблонизаторы дают возможность разграничения ответственности за содеяное: Если в шаблоне будет найдена бизнес логика, то это станет очевидным и позволит выявить нарушителя.
квики и смартиобразные шаблонизаторы не запрещают смешивать бизнес-логику и представление, хотя стараются и спрепятствуют этому смешанию.
{VAR} и < !-- BEGIN -->...<! — END --> запрещает же на корню.
но в замен в этом месте шаблонизаторы дают возможность разграничения ответственности за содеяное: Если в шаблоне будет найдена бизнес логика, то это станет очевидным и позволит выявить нарушителя.
Гм — не скажу, что это универсальнее. Ибо у вас появляется еще одно промежуточное звено — файл с логикой. И помоему тут постоянно путается логика приложения с логикой отображения.
Верстальщик может все товары прописать за 1руб. 00 коп. Просто заменив переменную на конкретное значение.
Верстальщик вообще шаблон может стереть.
Вот о чём и речь. При чём тут -30%?
кстати в вашем примере товар стоит {$cost} можно написать:
товар стоит 1 руб.
товар стоит 1 руб.
Бред какой-то говорите — у вас чего HTML передает сайту цены? Этак я у вас все за бесплатно куплю вы еще и должны будете. И верстальщик тут не виноват будет :-) Не аргумент это, а чего-то непонятное.
ну тоже верно =) ну тогда вообще можно сказать, что все что выводится не имеет значения — это же слова всего лишь, а настоящую покупку делаем в другом месте. это умозрительный пример
Ну не скажите, нотариус зафиксирует цену в 1 рубль, а вы с меня спишите 10 — я вас засужу а вы уж там сами будете рабираться почему и кто. только я никак не пойму — причем тут шаблонизатор? Верстальщик может поубивать синтаксиси ЛЮБОГО шаблонизатора и написать туда все, что хочет. Кстати, еще на ваш дата центр может упасть самолет и вообще сайта не останется. помоему примеры как раз из этой серии.
а что мешает эту скидку сделать девелоперу? А, точна! давайте мы запретим девелоперам прикосатся к коду! И тогда эту скидку сможет себе сделать девочка манагер у которой есть доступ в админку.
Может проще растрелять всех сотрудников, а магазин вообще закрыть?
Может проще растрелять всех сотрудников, а магазин вообще закрыть?
>Что есть шаблон в нашем контексте? Шаблон — это разметка страницы, в которую подставляются данные, сгенерированные бизнес-логикой.
Всё хорошо, но расстановка данных не может не смешиваться с логикой.
Так что мы или логику тащим в шаблон, или шаблон — в логику.
И вот тут уже проявляются особенности личных пристрастий.
Кто-то тащит "..." в код, а кто-то {if}...{/if} в шаблон.
Я отношусь ко вторым. Тонкостями шаблонизации должен заниматься шаблон. Логика должна быть связкой исходных данных и шаблона. ИМХО.
Всё хорошо, но расстановка данных не может не смешиваться с логикой.
Так что мы или логику тащим в шаблон, или шаблон — в логику.
И вот тут уже проявляются особенности личных пристрастий.
Кто-то тащит "..." в код, а кто-то {if}...{/if} в шаблон.
Я отношусь ко вторым. Тонкостями шаблонизации должен заниматься шаблон. Логика должна быть связкой исходных данных и шаблона. ИМХО.
Пардон, там серия b… /b тэгов в пример сожралась. Читать как:
Кто-то тащит "[b]...[/b]" в код, а кто-то {if}[b]...[/b]{/if} в шаблон.
Кто-то тащит "[b]...[/b]" в код, а кто-то {if}[b]...[/b]{/if} в шаблон.
может. в xslt, например.
Это однозначно логика представления, она должна быть где-то в шаблоне, или рядом, но никак не в коньтродллере.
логика представления должна быть в представлении, а не в шаблоне.
представление — это _програмный_ слой, ответственный за отображение модели.
синтаксис пхп для написания «логики» подходит куда больше, чем синтаксис любого шаблонизатора.
банально потому, что пхп предназначен для написания программ (логики), а шаблоны — для описания выходного формата (преобразования объектов используемого языка в тэги, аттрибуты и тп).
представление — это _програмный_ слой, ответственный за отображение модели.
синтаксис пхп для написания «логики» подходит куда больше, чем синтаксис любого шаблонизатора.
банально потому, что пхп предназначен для написания программ (логики), а шаблоны — для описания выходного формата (преобразования объектов используемого языка в тэги, аттрибуты и тп).
в общем часть этой мысли я говорил
developer.habrahabr.ru/blog/45370/#comment_1158848
кстати в вашей терминалогии можно сказать, что програмный_ слой, ответственный за отображение модели и есть шаблонизатор
developer.habrahabr.ru/blog/45370/#comment_1158848
кстати в вашей терминалогии можно сказать, что програмный_ слой, ответственный за отображение модели и есть шаблонизатор
Если мы используем смарти-шаблонизатор, то появляется возможность изменять переданные бизнес-логикой данные перед выдачей. А это не всегда приемлемо.
А с PHP -native аналогичной возможности нет? :)
А с PHP -native аналогичной возможности нет? :)
Ну, для начала, давайте так. Разработчики нифига не озлоблены :)
А теперь по теме. Давайте называть вещи своими именами.
PHP — шаблонизатор. Smarty -шаблонизатор, работающий на шаблонизаторе. Цель — неясна. Якобы, распутывание логики.
Вопрос по такому подходу.
Если вы выносите if-ы в отдельный шаблон — почему бы не выносить их и обрабатывать native? Бизнес-логику по-прежнему держать можно отдельно. В чем минус-то native? +)
А теперь по теме. Давайте называть вещи своими именами.
PHP — шаблонизатор. Smarty -шаблонизатор, работающий на шаблонизаторе. Цель — неясна. Якобы, распутывание логики.
Вопрос по такому подходу.
Если вы выносите if-ы в отдельный шаблон — почему бы не выносить их и обрабатывать native? Бизнес-логику по-прежнему держать можно отдельно. В чем минус-то native? +)
Разработчики нифига не озлоблены :)
PHP — шаблонизатор
я с вами не согласен, видимо вы путаете с PHP/FI
Сейчас PHP это объектноориентированный язык, с работай с сокетами, расшаренной памятью, акселераторами и очень богатыми возможностями
PHP — шаблонизатор
я с вами не согласен, видимо вы путаете с PHP/FI
Сейчас PHP это объектноориентированный язык, с работай с сокетами, расшаренной памятью, акселераторами и очень богатыми возможностями
Говоря о том, что PHP-шаблонизатор, я говорю не только о его прошлом. Но и текущих возможностях. Как был он шаблонизатором — так и содержит _ДО_СИХ_ПОР_ все возможности, которые были в FI.
Напомню, что сейчас PHP содержит все возможности для написания вермишели, в котором html соседствует с запросами к БД. Но ведь это не значит, что так и надо? :)
Каждый взрослый человек может делать всё тоже самое, что и маленький ребёнок, но это ещё не значит, что он всё ещё остался ребёнком.
Не следует путать имеющийся функционал и тот функционал, который реально применяется в данное время. Это утверждение(если утрировать) получается эквивалентно следующему: язык %langname% плох, потому что содержит _ДО_СИХ_ПОР_ возможность операции 2+2…
Не следует путать имеющийся функционал и тот функционал, который реально применяется в данное время. Это утверждение(если утрировать) получается эквивалентно следующему: язык %langname% плох, потому что содержит _ДО_СИХ_ПОР_ возможность операции 2+2…
теперь второй вопрос: что еще делают шаблонизаторы?
читаем: habrahabr.ru/blogs/php/27999/
итак, шаблонизаторы:
облегчают смену дизайна,
стимулируют писать меньше логики в шаблонах,
решают задачи кеширования,
решают задачи безопасности и это еще не все.
читаем: habrahabr.ru/blogs/php/27999/
итак, шаблонизаторы:
облегчают смену дизайна,
стимулируют писать меньше логики в шаблонах,
решают задачи кеширования,
решают задачи безопасности и это еще не все.
Давайте по-порядку :)
«Некоторые даже думают что шаблонизаторы созданы для дизайнеров/верстальщиков, а программисту они не нужны. Так вот, все это миф. Шаблонизатор это программа созданная для того, что бы сделать разделение логик удобнее, предоставляющая некоторые расширенные функции, но она никак не является камнем преткновения.»
На кой мне сдался шаблонизатор, контроль которого один фиг осуществлять мне? Подумайте над этим. Шаблонизаторы а-ля 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. Да?
«Некоторые даже думают что шаблонизаторы созданы для дизайнеров/верстальщиков, а программисту они не нужны. Так вот, все это миф. Шаблонизатор это программа созданная для того, что бы сделать разделение логик удобнее, предоставляющая некоторые расширенные функции, но она никак не является камнем преткновения.»
На кой мне сдался шаблонизатор, контроль которого один фиг осуществлять мне? Подумайте над этим. Шаблонизаторы а-ля 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. Да?
>Подумайте над этим. Шаблонизаторы а-ля str_replace ЛИШАЮТ возможности ошибиться дизайнеру => мне не нужно его контроллировать. Гениально, правда? :)
Ещё раз. Было в шаблоне:
Цена:%price%
Стало в результате вмешательства дизайнера:
Цена:1 руб.
str_replace спасёт от такого?
Ещё раз. Было в шаблоне:
Цена:%price%
Стало в результате вмешательства дизайнера:
Цена:1 руб.
str_replace спасёт от такого?
Вы уже выяснили?
Мы говорим о логике (и бизнес-логике и о логике разметки). Причем тут диверсия?
Мы говорим о логике (и бизнес-логике и о логике разметки). Причем тут диверсия?
При том, что -30% могут быть тоже только при сознательной диверсии дизайнера :)
…
Кстати, тут, вот, многие вообще ратуют за использование чистого PHP в роли шаблониатора. Так из такого «шаблона» дизайнер даже БД подправить может :)
…
В общем, можно сайтись на уровне бесконтрольного доверия к дизайнеру.
Кто предпочитает вообще всё делать сам — может заюзать и PHP, если не видит в нём неудобства.
Кому дизайном заниматься влом, кто не против наличия кусков шаблона в коде и дизайнер наличествует, но доверия ему нет — для того и str_replace — шаблонизатор.
Наконец, кто доверяет дизайнеру, хочет разделить бизнес-логику, оставив её в Controller'е с логикой отображения, перенеся её во View, то выбор того, как раз, решения, типа Smarty, Quicky, ctpp и т.п. :)
…
Кстати, тут, вот, многие вообще ратуют за использование чистого PHP в роли шаблониатора. Так из такого «шаблона» дизайнер даже БД подправить может :)
…
В общем, можно сайтись на уровне бесконтрольного доверия к дизайнеру.
Кто предпочитает вообще всё делать сам — может заюзать и PHP, если не видит в нём неудобства.
Кому дизайном заниматься влом, кто не против наличия кусков шаблона в коде и дизайнер наличествует, но доверия ему нет — для того и str_replace — шаблонизатор.
Наконец, кто доверяет дизайнеру, хочет разделить бизнес-логику, оставив её в Controller'е с логикой отображения, перенеся её во View, то выбор того, как раз, решения, типа Smarty, Quicky, ctpp и т.п. :)
Уважаемый, вот у меня вообще нет представления в коде. А сделано это благодаря «дроблению» дизайна на куски, которые в смарти через if-ы собираются. Это раз.
Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)
Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)
>Уважаемый, вот у меня вообще нет представления в коде. А сделано это благодаря «дроблению» дизайна на куски, которые в смарти через if-ы собираются. Это раз.
Как и у меня. Я уже не раз писал, что считаю код [отображения] в представлении меньшим злом, чем представление — в коде.
>Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)
Простите, но с str_replace вы не можете сделать ни одного нормального отображения без представления в коде.
Как Вы без представления в коде с помощью str_replace реализуете конструкцию:
код:
if($important) $title = "[b]{$title}[/b]";
шаблон:
[td]%title%[/td]
Поясните на примере.
Как и у меня. Я уже не раз писал, что считаю код [отображения] в представлении меньшим злом, чем представление — в коде.
>Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)
Простите, но с str_replace вы не можете сделать ни одного нормального отображения без представления в коде.
Как Вы без представления в коде с помощью str_replace реализуете конструкцию:
код:
if($important) $title = "[b]{$title}[/b]";
шаблон:
[td]%title%[/td]
Поясните на примере.
Ну, например, вот так:
$data = $this->db->getItem('SELECT * FROM articles LIMIT 0, 1');
$data['title'] = $important? $data['title']: $HTML_Tags->b(data['title']);
$html = Template::mountVars('tmpl_name', $data);
$data = $this->db->getItem('SELECT * FROM articles LIMIT 0, 1');
$data['title'] = $important? $data['title']: $HTML_Tags->b(data['title']);
$html = Template::mountVars('tmpl_name', $data);
> $HTML_Tags->b(data['title']);
Вот это и есть перенос шаблона в код. Только в ещё более извращённой форме. HTML_Tags->b() код приводить будем? :)
Кстати:
>$data = $this->db->getItem('SELECT * FROM
Это — уже очень и очень многое говорит об уровне обсуждаемых проектов :)
Простановка SQL-запросов в коде — это ещё хуже, чем шаблоны :D
Вот это и есть перенос шаблона в код. Только в ещё более извращённой форме. HTML_Tags->b() код приводить будем? :)
Кстати:
>$data = $this->db->getItem('SELECT * FROM
Это — уже очень и очень многое говорит об уровне обсуждаемых проектов :)
Простановка SQL-запросов в коде — это ещё хуже, чем шаблоны :D
имеется вииду что из шаблонизатора вам трудно «убить» систему (стереть например что либо)
Извольте. Мы говорим о шаблонизаторе — о работе с представлением. Причем тут убийство системы? Шаблонизатор должен заниматься только представлением (пришли данные — смонтировал. ). Ничего удалять он вообще не должен. Ни данные, ни файлы… Не должно быть такого функционала в принципе.
Если шаблонизатор позволяет делать такие вещи — то это уже новый язык программирования, почти… =)
Если шаблонизатор позволяет делать такие вещи — то это уже новый язык программирования, почти… =)
developer.habrahabr.ru/blog/45370/#comment_1146167
пример взят выше просто с диверсией, я мож перепутал?
пример взят выше просто с диверсией, я мож перепутал?
Воооот и нарисовывается золотая середина между нативностью и удобством. =)
В логике шаблонизатора верстальщик может запутаться, а в коде — натворить чего не так.
// по крайней мере, для меня, она нарисовалась года 2-2.5 назад. А сейчас общими усилиями к ней подходим.
В логике шаблонизатора верстальщик может запутаться, а в коде — натворить чего не так.
// по крайней мере, для меня, она нарисовалась года 2-2.5 назад. А сейчас общими усилиями к ней подходим.
я так понимаю, что шаблонизатор делается так, чтоб запутаться было сложнее.
Вы искренне верите, что в Смарти нельзя запутаться верастальщику? Лично знаю парочку, которая чуть не плачет и просит программистов переписать работу с шаблонами.
можно, но сложнее чем на пхпнайтив.
Наберусь смелости, и прокомменитрую:)
Я почти паралельно работаю с двумя проэктами.
В одном — PHP Native отображение.
Во втором — Smarty.
Вот не поверите, но со смарти мне работать куда удобней, потому что чистый РНР содержит много лишнего кода, который в смарти можно описать одним тэгом. И выглядит в эклипсе акуратней именно смарти (субъективное мнение).
Еще бы его научить подсвечивать и валидировать Smarty тэги, сказка была бы.
Я почти паралельно работаю с двумя проэктами.
В одном — PHP Native отображение.
Во втором — Smarty.
Вот не поверите, но со смарти мне работать куда удобней, потому что чистый РНР содержит много лишнего кода, который в смарти можно описать одним тэгом. И выглядит в эклипсе акуратней именно смарти (субъективное мнение).
Еще бы его научить подсвечивать и валидировать Smarty тэги, сказка была бы.
Да, возможно вы правы, насчет пользовательских функций и т.д., но стает актуальным, в таком случае, вопрос — зачем изобретать «велосипед»?
Хотя, это опять таки большая тема для рассуждений. Кому-то нравится свои изобретения, кому-то больше по душе уже готовые решения.
P.S. Большое спасибо за ссылку.
Хотя, это опять таки большая тема для рассуждений. Кому-то нравится свои изобретения, кому-то больше по душе уже готовые решения.
P.S. Большое спасибо за ссылку.
стимулируют писать меньше логики в шаблонах
А кто сказал, что в шаблонах надо как можно меньше логики? Вроде ведь решили уже, что шаблоны программистам нужны. А они (программисты) с логикой должны по роду службы дружить :)
И, да — шаблонизаторы не для отделения логики представления служат, вовсе нет. А для отделения логики приложения от логики представления. Не надо выкидывать слова из песни :)
А кто сказал, что в шаблонах надо как можно меньше логики? Вроде ведь решили уже, что шаблоны программистам нужны. А они (программисты) с логикой должны по роду службы дружить :)
И, да — шаблонизаторы не для отделения логики представления служат, вовсе нет. А для отделения логики приложения от логики представления. Не надо выкидывать слова из песни :)
>Если вы выносите if-ы в отдельный шаблон — почему бы не выносить их и обрабатывать native?
Потому что, в коде начинают вылезать конструкции, типа if($important) $title = "{$title}". А в коде они смотрятся намного печальнее, чем {if} в шаблоне.
Потому что, в коде начинают вылезать конструкции, типа if($important) $title = "{$title}". А в коде они смотрятся намного печальнее, чем {if} в шаблоне.
<?php $title = $important? '': "{$title}" ?> — не катит?
Мы тут смешивает три вида шаблонов.
1. Чистый PHP
2. «str_replace»
3. и «продвинутые шаблонизаторы»
Мой комментарий относился ко второму.
Ваш — к первому.
В общем — см. последние три абзаца в developer.habrahabr.ru/blog/45370/#comment_1146371
1. Чистый PHP
2. «str_replace»
3. и «продвинутые шаблонизаторы»
Мой комментарий относился ко второму.
Ваш — к первому.
В общем — см. последние три абзаца в developer.habrahabr.ru/blog/45370/#comment_1146371
Я сторонник второго варианта, повторюсь. И против третьего. На лбу, что-ли, написать =)
Хорошо, я постарался Вас запомнить :) Просто, если вы знакомы с соционикой, я отношусь к квестимным типам и обычно не с незнакомым мне собеседником общаюсь, а обсуждаю поднимаемую им проблему. Соответственно, при наличии N собеседников при N>>1 в смешанном древовидном обсуждении взаимопротиворечащих вопросов уже почти нереально сопоставлять собеседника со сказанными им когда-то ранее :)
Теперь буду помнить, что Вы — это «str_replace» :)
Теперь буду помнить, что Вы — это «str_replace» :)
Ммм… ну вот Zend_View можно назвать шаблонизатором?
Памому нет. И идея другая и реализация тоже другая. Но функции возложенные на шаблонизаторы выполняет и не имеет тех недостатков которые присущи типичным шаблонизаторам (Smarty).
Памому нет. И идея другая и реализация тоже другая. Но функции возложенные на шаблонизаторы выполняет и не имеет тех недостатков которые присущи типичным шаблонизаторам (Smarty).
разверните ваше сообщение пожалуйста
ок. Щас попробую.
Вот в топике было ясно сказано: Нужны ли шаблонизаторы?
Но не совсем понятно что понимается под шаблонизатором.
Предположим что имелось ввиду что то типа Smarty.
Тогда сразу возникает аргумент в пользу того что есть более изящные и быстрые релизации тех задач которые выполняет Smarty но при этом в не являющимися «шаблонизаторами» так как их понимает автор топика.
Предположим что вопрос стоял шире и имелся ввиду извечный вопрос: Должны ли шаблоны быть смесью php и html или надо придумать свой язык описания шаблонов.
Тогда возникает встречный вопрос: А чем не устраивает смесь php+html кроме того что приходится писать более сложные скобки и имеется шанс наступить на грабли незаметно для себя перенеся локику в шаблон.
Ну вот както так.
Вот в топике было ясно сказано: Нужны ли шаблонизаторы?
Но не совсем понятно что понимается под шаблонизатором.
Предположим что имелось ввиду что то типа Smarty.
Тогда сразу возникает аргумент в пользу того что есть более изящные и быстрые релизации тех задач которые выполняет Smarty но при этом в не являющимися «шаблонизаторами» так как их понимает автор топика.
Предположим что вопрос стоял шире и имелся ввиду извечный вопрос: Должны ли шаблоны быть смесью php и html или надо придумать свой язык описания шаблонов.
Тогда возникает встречный вопрос: А чем не устраивает смесь php+html кроме того что приходится писать более сложные скобки и имеется шанс наступить на грабли незаметно для себя перенеся локику в шаблон.
Ну вот както так.
честно скажу, как автор топика, что принимаю, что мое мнение субъективно, потому готов поговорить на тему
мож я их тоже считаю шаблонизаторами? конкретней о каких решениях идет речь и в чем принципиальное отличие от популярных аналогов.
вообще очень важный стимул использовать шаблонизатор для меня.
а вообще обе трактовки вопроса, верны!
более изящные и быстрые релизации тех задач которые выполняет Smarty но при этом в не являющимися «шаблонизаторами»
мож я их тоже считаю шаблонизаторами? конкретней о каких решениях идет речь и в чем принципиальное отличие от популярных аналогов.
имеется шанс наступить на грабли незаметно для себя перенеся локику в шаблон
вообще очень важный стимул использовать шаблонизатор для меня.
а вообще обе трактовки вопроса, верны!
Ну тогда нужны. :)
Поповоду реализаций я там уже показывал Zend_View. Его можно использовать отдельно от всего ZF.
Щас пост превратится в рекламу :)
Ну что он умеет.
— Разделять логику и представление умеет.
— Мехнизм хелперов присутствует (плагины в смарти).
— Кеширование не его задача, для этого есть отдельный механизм.
— В качестве шаблона используется самое быстрое что есть в пхп — смесь php и html.
— Обьектная модель ёпт :):
//php
$this->view->user_profile = $model->getUser(''345");
//шаблон
echo «Welcome, », $this->user_profile['user_login'];
— Всякие хитрые штуки типа partial и partialLoop:
<?php // partial.phtml ?>
<?= $this->partial('partial.phtml', array(
'from' => 'Team Framework',
'subject' => 'view partials')); ?>
— layout'ы
— head* хелперы.
Ну там много всякого и для программиста и для дизайнера.
Т.е что я хочу сказать? Я хочу сказать что вот такие шаблонизаторы если это можно назвать шаблонизатором — нужны и это ИМХО лучшее что можно придумать для разработчика на пхп.
А вот такого рода штуки типа того же смарти — я не юзал бы.
Поповоду реализаций я там уже показывал Zend_View. Его можно использовать отдельно от всего ZF.
Щас пост превратится в рекламу :)
Ну что он умеет.
— Разделять логику и представление умеет.
— Мехнизм хелперов присутствует (плагины в смарти).
— Кеширование не его задача, для этого есть отдельный механизм.
— В качестве шаблона используется самое быстрое что есть в пхп — смесь php и html.
— Обьектная модель ёпт :):
//php
$this->view->user_profile = $model->getUser(''345");
//шаблон
echo «Welcome, », $this->user_profile['user_login'];
— Всякие хитрые штуки типа partial и partialLoop:
<?php // partial.phtml ?>
- From: <?= $this->escape($this->from) ?>
- Subject: <?= $this->escape($this->subject) ?>
<?= $this->partial('partial.phtml', array(
'from' => 'Team Framework',
'subject' => 'view partials')); ?>
— layout'ы
— head* хелперы.
Ну там много всякого и для программиста и для дизайнера.
Т.е что я хочу сказать? Я хочу сказать что вот такие шаблонизаторы если это можно назвать шаблонизатором — нужны и это ИМХО лучшее что можно придумать для разработчика на пхп.
А вот такого рода штуки типа того же смарти — я не юзал бы.
голос принят. Доступно и понятно
Мне код не нравится, много лишнего, всюду $this, прочто было бы лень постоянно это писать, да и читать тяжелее. Трюк с partial() -> это просто что-то вроде хелпера в квики.
Layouts — извратный способ решения, когда есть например наследование шаблонов.
Layouts — извратный способ решения, когда есть например наследование шаблонов.
Много лишнего? Что конкретно? Приведите пример который делает тоже самое. По меряемся чтоль количеством символов. :)
Лень? Плохой аргумент :)
Используйте удобные IDE.
Читать тяжелее? Слишком субъективно. Мне не тяжело вот.
partial() — и есть хелпер. Всё дело в том что с чем сравнивать.
Наследование шаблонов, имхо, как раз то что может запутать дизайнера.
Опять же для кого что является извращением. Для меня как раз наследование шаблонов — извращение.
Лень? Плохой аргумент :)
Используйте удобные IDE.
Читать тяжелее? Слишком субъективно. Мне не тяжело вот.
partial() — и есть хелпер. Всё дело в том что с чем сравнивать.
Наследование шаблонов, имхо, как раз то что может запутать дизайнера.
Опять же для кого что является извращением. Для меня как раз наследование шаблонов — извращение.
> Используйте удобные IDE
Не аргумент. Большинство разработчиков ИДЕ плевать хотели на оптимизацию, производительность и использование подходящих языков для разработки, так чот мне с ними не по пути, не хочу пользоваться некачественным продуктом.
И вообще, что за аргумент? Учить горячие клавиши, писать сниппеты только из-за того, что у какого-то там разработчика отсутствует мозг и он не умеет кратко и понятно выражаться (а $this-> — это лишнеее, так как встречается у вас почти в каждой строке)
> Читать тяжелее? Слишком субъективно. Мне не тяжело вот.
Конечно. на файле в 10 строк не тяжелее. Возьмите что-нибудь посерьезней. килобайт на 30.
> partial() — и есть хелпер.
Плохой хелпер. мне такой не нужен, так как не хочу на каждый хелпер по файлу отводить, это ж помойка почище смарти получится. Да и спроизводительностьбю фейл, один большой файл парсится быстрее чем много маленьких. Хочу все хелперы в файле helpers.tpl.
С помощью наследования (специально для дизайнера) можно при желании имитировать схему с layout, а можно и что-то более сложное.
в общем, вот как выглядит хороший шаблон вместо вашего плохого:
helpers.tpl:
{helper name=«partial» data=array()}
From: {HTML:$data.from}
Subject: {HTML:$data.subject}
{/helper}
Главный файл
{include file=«helpers.tpl»/}
{helper:partial data=array(
'from' => 'Team Framework',
'subject' => 'view partials')}
Не аргумент. Большинство разработчиков ИДЕ плевать хотели на оптимизацию, производительность и использование подходящих языков для разработки, так чот мне с ними не по пути, не хочу пользоваться некачественным продуктом.
И вообще, что за аргумент? Учить горячие клавиши, писать сниппеты только из-за того, что у какого-то там разработчика отсутствует мозг и он не умеет кратко и понятно выражаться (а $this-> — это лишнеее, так как встречается у вас почти в каждой строке)
> Читать тяжелее? Слишком субъективно. Мне не тяжело вот.
Конечно. на файле в 10 строк не тяжелее. Возьмите что-нибудь посерьезней. килобайт на 30.
> partial() — и есть хелпер.
Плохой хелпер. мне такой не нужен, так как не хочу на каждый хелпер по файлу отводить, это ж помойка почище смарти получится. Да и спроизводительностьбю фейл, один большой файл парсится быстрее чем много маленьких. Хочу все хелперы в файле helpers.tpl.
С помощью наследования (специально для дизайнера) можно при желании имитировать схему с layout, а можно и что-то более сложное.
в общем, вот как выглядит хороший шаблон вместо вашего плохого:
helpers.tpl:
{helper name=«partial» data=array()}
From: {HTML:$data.from}
Subject: {HTML:$data.subject}
{/helper}
Главный файл
{include file=«helpers.tpl»/}
{helper:partial data=array(
'from' => 'Team Framework',
'subject' => 'view partials')}
>> Конечно. на файле в 10 строк не тяжелее. Возьмите что-нибудь посерьезней. килобайт на 30.
При описанном мной подходе файлы по 30 килобайт встретить практически невозможно. Максимум на два экрана текста.
>>Плохой хелпер. мне такой не нужен, так как не хочу на каждый хелпер по файлу отводить, это ж помойка почище смарти получится. Да и спроизводительностьбю фейл, один большой файл парсится быстрее чем много маленьких. Хочу все хелперы в файле helpers.tpl.
та пишите где хотите, не заставляет же никто выносить каждый хелпер в отдельный файл.
>>>в общем, вот как выглядит хороший шаблон вместо вашего плохого:
Я вот чесно, с первого раза так и не догадался что такое: HTML:$data.from :)
Подведу итог.
Наш спор пронизан субъективизмом. Давайте не углубляться а то перейдем на личности :)
При описанном мной подходе файлы по 30 килобайт встретить практически невозможно. Максимум на два экрана текста.
>>Плохой хелпер. мне такой не нужен, так как не хочу на каждый хелпер по файлу отводить, это ж помойка почище смарти получится. Да и спроизводительностьбю фейл, один большой файл парсится быстрее чем много маленьких. Хочу все хелперы в файле helpers.tpl.
та пишите где хотите, не заставляет же никто выносить каждый хелпер в отдельный файл.
>>>в общем, вот как выглядит хороший шаблон вместо вашего плохого:
Я вот чесно, с первого раза так и не догадался что такое: HTML:$data.from :)
Подведу итог.
Наш спор пронизан субъективизмом. Давайте не углубляться а то перейдем на личности :)
Я пишу на PHP около 8 лет. И до него (и после) много писал на других языках. Уже в аккурат 20 лет…
При этом PHP мне не очень нравится. Есть языки для его основных задач подходящие лучше. Хотя есть и хуже. Но я его считаю как раз вполне себе полноценным языком, ориентированным на web и считаю востребованным шаблонизаторы, пишущиеся на нём.
При этом PHP мне не очень нравится. Есть языки для его основных задач подходящие лучше. Хотя есть и хуже. Но я его считаю как раз вполне себе полноценным языком, ориентированным на web и считаю востребованным шаблонизаторы, пишущиеся на нём.
>Но, на мой взгляд, коль скоро РНР уже является ещё и шаблонизатором, плодить сущности, коими являются тысячи
Видишь ли, Си — это уже язык программирования. Так зачем плодить сущности и писать на нём PHP, Python, Perl? :)
Java — это уже язык. Зачем на нём писать Jython, JRuby, Rhino, Quercus, Scala? :)
>Ух ты. А на чём программировать начинали (язык/платформа)?
Ну, «коммерческий» стаж у меня поменьше 20 лет :) Лет 15 где-то. Программировать вообще начинал на программируемых калькуляторах, на Фокале на БК-0010 и Бейсике на ДВК. «Коммерцией» начинал заниматься на ассемблере 8080, Форте и QB на x86.
Из того, на чём _много_ доводилось писать — это (в порядке знакомства) Бейсики, ассемблеры, Форты, Си/Си++, Perl, PHP, Java.
Видишь ли, Си — это уже язык программирования. Так зачем плодить сущности и писать на нём PHP, Python, Perl? :)
Java — это уже язык. Зачем на нём писать Jython, JRuby, Rhino, Quercus, Scala? :)
>Ух ты. А на чём программировать начинали (язык/платформа)?
Ну, «коммерческий» стаж у меня поменьше 20 лет :) Лет 15 где-то. Программировать вообще начинал на программируемых калькуляторах, на Фокале на БК-0010 и Бейсике на ДВК. «Коммерцией» начинал заниматься на ассемблере 8080, Форте и QB на x86.
Из того, на чём _много_ доводилось писать — это (в порядке знакомства) Бейсики, ассемблеры, Форты, Си/Си++, Perl, PHP, Java.
Для всех замечу: сходство ников случайно — мы из разных банд!
Плюс один за XSLT. Надо на него переходить +)
ага тоесть уже отказываетесь от str_replace
Никто не говорил, что str_replace лишен недостатков. Это же очевидно :)
Просто лично для меня гораздо удобнее. Для дизайнеров удобнее. Для «программистов после» меня разобраться в шаблонизаторе = прочесть один класс в 70 строк кода.
А XSLT — это маяк впереди. По примерам видел, что много чего красивого можно сделать, не выдумывая «условно_человеческую_логику» :)
Просто лично для меня гораздо удобнее. Для дизайнеров удобнее. Для «программистов после» меня разобраться в шаблонизаторе = прочесть один класс в 70 строк кода.
А XSLT — это маяк впереди. По примерам видел, что много чего красивого можно сделать, не выдумывая «условно_человеческую_логику» :)
Тут опять же субъективно. Я года три назад спрыгнул с XSLT, хотя до этого активно их пользовал. Ни разу не сожалею, хотя, конечно, понимаю, что технология сильная.
расскажите пожалуйста почему слезли с них
Для неподготовленного верстальщика они весьма трудоёмки. Осваивать новые технологии никто не хотел, а перспектива быть единственный верстальщиком (не люблю вёрстку шаблонов в принципе, будь то чистое PHP, XSL или Смарти) мне не улыбалась :) Поэтому я не стал особо настаивать на нововведениях в рабочий процесс.
Шаблонизаторы нужны, чтобы бить по рукам тех, кто хочет запихать логику в шаблон. И мне на это обычно никакой производительности не жалко. Лично у меня очень консервативный взгляд на структуру. База должна быть просто свалкой данных. Шаблонизатор должен просто втыкать переменные в нужные места HTML разметки. Этот вариант оптимален. Можно использовать в базе триггеры и отказываться от шаблонов. Но только если это оправдано какими-то соображениями.
Лучший шаблонизатор у Django. Ничего лишнего не позволяет.
Лучший шаблонизатор у Django. Ничего лишнего не позволяет.
лучший шаблонизатор. мы пока воюем нужен ли он вообще.
> Шаблонизатор должен просто втыкать переменные в нужные места HTML разметки.
Это верно до тех пор, пока вы не столкнетесь с тем, что перед тем, как воткнуть в нужное место, это место надо ВЫЧИСЛИТЬ. То есть появляется т. н. «логика представления» и которую ну никаким макаром бизнес-логике отнести нельзя.
Это верно до тех пор, пока вы не столкнетесь с тем, что перед тем, как воткнуть в нужное место, это место надо ВЫЧИСЛИТЬ. То есть появляется т. н. «логика представления» и которую ну никаким макаром бизнес-логике отнести нельзя.
Опять таки ни разу ещё не встречал задачи, с которой бы не справился Django-шаблонизатор. Наследование шаблонов, if и for — всё что нужно. В принципе когда доводилось работать с очень хорошими верстальщиками они просто давали разный css для разных типов страниц и всё само перевёрстывалось до неузнаваемости. Но таких мало.
Шаблонизаторы нужны, чтобы бить по рукам тех, кто хочет запихать логику в шаблон.
Вы слишком категоричны :) От логики в любом случае не уйти. Не будет в шаблонах логики отображения — будет в контроллере.
Лучший шаблонизатор у Django. Ничего лишнего не позволяет. Хороший, но лучшим бы я его не назвал. Ничего лишнего не позволяет, но запрещает много чего полезного. Чего стоят три тега {% if %} + {% ifequal %} + {% ifnotequal %} вместо одного {% if %} с поддержкой операторов. Хотя, коль скоро Вы логику не используете в принципе, мою точку зрения наверняка не оцените ;)
Вы слишком категоричны :) От логики в любом случае не уйти. Не будет в шаблонах логики отображения — будет в контроллере.
Лучший шаблонизатор у Django. Ничего лишнего не позволяет. Хороший, но лучшим бы я его не назвал. Ничего лишнего не позволяет, но запрещает много чего полезного. Чего стоят три тега {% if %} + {% ifequal %} + {% ifnotequal %} вместо одного {% if %} с поддержкой операторов. Хотя, коль скоро Вы логику не используете в принципе, мою точку зрения наверняка не оцените ;)
Не оценю. Какая нафиг логика в шаблоне? Заполнено поле — вывести, не заполнено — не выводить. Всё. Нечего тут сравнивать с логикой в модели / конроллере. Там она сколь угодно сложной может быть. И, по крайней мере, нормальный шаблонизатор никогда не позволит «подхачить» юному дарованию и преопределить, например, сессионную переменную (как это позволяет тот же Zend_View). Понятно, что за такое надо руки отрывать, но перед этим придётся ещё несколько часов побится головой об монитор, чтобы найти такую шутку. В топку такое удовольствие.
Про шаблоны. Вот радости-то написать {% if a eq b %} вместо {% ifequal a b %}. Попробуйте относится к ним как к if с прилепленным оператором. )
Про шаблоны. Вот радости-то написать {% if a eq b %} вместо {% ifequal a b %}. Попробуйте относится к ним как к if с прилепленным оператором. )
Какая нафиг логика в шаблоне? Заполнено поле — вывести, не заполнено — не выводить. Всё.
Наибанальнейший пример: раскраска строк таблицы «зеброй». Дизайнер может решить, что она нужна. А может и не решить. Зачем перегружать контроллер заведомо оформительской логикой?
И, по крайней мере, нормальный шаблонизатор никогда не позволит «подхачить» юному дарованию и преопределить, например, сессионную переменную (как это позволяет тот же Zend_View).
Следует ли это читать как «шаблонизаторы на нативном пхп — ацтой, даёшь собственный макроязык»? Они (шаблонизаторы на нативном пхп) ведь это позволяют :)
В принципе можно такую раскраску запихать как в шаблонизатор, так и в модель. Я предпочитаю всё делать на уровне модели. Опять таки какая разница, где писать "$i % 2?…: ..."?
Да, я очень не люблю «шаблонизаторы» вида include 'template.php' и все их подвиды. Пока меня ещё никто не убедил, что в таком подходе есть какие-то преимущества.
Да, я очень не люблю «шаблонизаторы» вида include 'template.php' и все их подвиды. Пока меня ещё никто не убедил, что в таком подходе есть какие-то преимущества.
В принципе можно такую раскраску запихать как в шаблонизатор, так и в модель.
А зачем перегружать модель избыточными данными, которые ну совсем никак ей не нужны?
Вопрос риторический? Мне в модели и дескрипшен не нужен. Что ж его теперь из базы не тянуть? Просто у меня такой подход. Все управленческие функции возлагаются на модель. База служит грудой информации, шаблон — местом втыкания информации. Для всего остального есть модель. Такой вариант мне удобнее всего.
Повторюсь, в случае необходимости я могу работать по другому, навтыкав в базу foregin key'ев в режиме cascade и терпя использование верстальщиком вольностей Smarty. В случае, если мне объяснят, зачем это нужно. Ну или если это просто критично для командной разработки.
Повторюсь, в случае необходимости я могу работать по другому, навтыкав в базу foregin key'ев в режиме cascade и терпя использование верстальщиком вольностей Smarty. В случае, если мне объяснят, зачем это нужно. Ну или если это просто критично для командной разработки.
>Все управленческие функции возлагаются на модель
обычно управляет контроллер, обрабатывает модель, выводит вьювер. то что у вас часть модели занята логикой вывода — это означает что сильная связь между элементами вьювера и модели. Попробуйте разбить эту логику на 2 сущности (я не призываю вас к шаблонизаторам, просто разбить), тогда вы получите разные сферы деятельности: деятельность направленная на обработку данных, деятельность направленная на отображение данных
обычно управляет контроллер, обрабатывает модель, выводит вьювер. то что у вас часть модели занята логикой вывода — это означает что сильная связь между элементами вьювера и модели. Попробуйте разбить эту логику на 2 сущности (я не призываю вас к шаблонизаторам, просто разбить), тогда вы получите разные сферы деятельности: деятельность направленная на обработку данных, деятельность направленная на отображение данных
мне кажется у вас буковка в нике пропущена.
Почему-то комментарий отправился сам, решив не спрашивать, дописал я его или нет. Остался вопрос про операторы. По-моему, 3 однотипных тега, хотя достаточно бы и одного — это прямое нарушение заветов Оккама ;)
все кто учавствует в войне просьба: проплюсуйте топик, долго еще сможем сюда отправлять всех кто хочет воевать в других местах!
Перенесите топик в блог «Я Умный!»
А где вОйны-то? Где озлобленные разработчики? Или я чего-то не понимаю?
Если вы хотите назвать букву «V» из аббревиатуры «MVC» каким-то особенным словом — назовите. Но это слово всё равно будет отвечать за представление и логику представления.
P.S. Ну разве что топик для тех, кто не пользуется этом паттерном.
Если вы хотите назвать букву «V» из аббревиатуры «MVC» каким-то особенным словом — назовите. Но это слово всё равно будет отвечать за представление и логику представления.
P.S. Ну разве что топик для тех, кто не пользуется этом паттерном.
1) Шаблонизатор нужен хотя бы для того, чтобы сделать код шаблона читабельнее. Так как {$title|escape} смотрится в разы лучше чем, не так ли? В таком коде легче разобраться, меньше вероятность ошибки, да и писать легче.
2) Всякую хрень вроде date_format, number_format легче вынести в шаблон, чем в контроллере делать эти вечны6е циклы типа
foreach ($data as $k=>$row)
{
$data[$k]['date'] = date($format, $row['date']);
}
Это изврат тот еще.
3) Нужно наследование шаблонов (а-ля Джанго) — тоже классная вещь, позволяет менять части родительского шаблона без извратов и тонны ифов (которые тоже подрывают идеологию понятности и наглядности).
4) кода в шаблоне конечно по идее не должно быть, но в ситуациях вроде вывода в несколько колонок, или например по кругу — не выносить же логику представления в контроллер, поэтому код тут все же нужен(( Видимо надо либо прикручивать php файлик с расчетом координат к шаблону, либо прямло в шаблоне в тдельной секции считать, мне второе было бы удобнее.
В общем, я за наглядный шаблон, который понятен и потому легче редактировать, меньше вероятность наделать ошибок.
XSLT кстати поэтому не нравится, XML-подобные языки вообще плохо воспринимаются человеком.
2) Всякую хрень вроде date_format, number_format легче вынести в шаблон, чем в контроллере делать эти вечны6е циклы типа
foreach ($data as $k=>$row)
{
$data[$k]['date'] = date($format, $row['date']);
}
Это изврат тот еще.
3) Нужно наследование шаблонов (а-ля Джанго) — тоже классная вещь, позволяет менять части родительского шаблона без извратов и тонны ифов (которые тоже подрывают идеологию понятности и наглядности).
4) кода в шаблоне конечно по идее не должно быть, но в ситуациях вроде вывода в несколько колонок, или например по кругу — не выносить же логику представления в контроллер, поэтому код тут все же нужен(( Видимо надо либо прикручивать php файлик с расчетом координат к шаблону, либо прямло в шаблоне в тдельной секции считать, мне второе было бы удобнее.
В общем, я за наглядный шаблон, который понятен и потому легче редактировать, меньше вероятность наделать ошибок.
XSLT кстати поэтому не нравится, XML-подобные языки вообще плохо воспринимаются человеком.
1)Но на том же смарти проблематично работать с древовидными структурами, мы конечно сделали маленький хак в виде плагина под смарти для обработки XSLT (http://tkf.habrahabr.ru/blog/45184/).
2) да это действительно не выход, читабельность ухудшается в разы
3) с Django не работал, надо будет попробовать.
А вообще шаблонизатор сильно упрощает работу, и верстальщику надо знать лишь синтаксис шаблонизатора, а не стараться вставлять свои куски html кода в php код. Да еще так чтобы ничего не обрушить
2) да это действительно не выход, читабельность ухудшается в разы
3) с Django не работал, надо будет попробовать.
А вообще шаблонизатор сильно упрощает работу, и верстальщику надо знать лишь синтаксис шаблонизатора, а не стараться вставлять свои куски html кода в php код. Да еще так чтобы ничего не обрушить
простите, но древовидные структуры вывидет любой шаблонизатор с хелперами: тотже Квики habrahabr.ru/blogs/php/45337/ или ZF
А почему бы тогда не сделать смарти- или джанго- подобный промежутточный слой? Хотя, если вам удобно — пользуйтесь, а мне тяжело, так как XML-теги визуально смешиваются с HTML (и те, и те в угловых скобках), да и вообще, ИМХО — XML не для человека, а для машины.
XML глазами намного проще смотреть чем поток данных =)
Ну возможно надо просто поработать как следует поработать с XSLT, но все-таки мне синтаксис не нравится, и все. А пример с my:sort я бы записал как ORDER BY `last Name` ASC, `First Name` ASC — уж насколько проще и понятней.
А well-formedness, ИМХО, не аргумент, смарти тоже ругается на неправильный порядок тегов.
А well-formedness, ИМХО, не аргумент, смарти тоже ругается на неправильный порядок тегов.
Что тут непонятного, ё-моё)) XSLT теги визуально похожи на HTML (тоже в скобках), и не выделяются с перевого взгляда, а смарти (к примеру) со своим {$… } как раз очень четко выделяется. Хотя за упомянутых вами верстальщиков сказать не могу, может им так и привычнее, кто знает.
Но XML — выглядит мерзко. HTML — нет, так как там много коротких тегов типа [p], много информации хранится в аттрибутах тегов и он смотрится аккуратно, а XML смотрится как каша из тегов. по другому не скажешь.
Смотрите сами:
< xsl:stylesheet
version=«1.0»
xmlns:xsl=«www.w3.org/1999/XSL/Transform»
xmlns:fo=«www.w3.org/1999/XSL/Format»
xmlns:axsl=«www.w3.org/1999/XSL/TransformAlias» >
< xsl:namespace-alias stylesheet-prefix=«axsl» result-prefix=«xsl»/ >
< xsl:template match="/" >
< axsl:stylesheet >
< xsl:apply-templates/ >
< /axsl:stylesheet >
< /xsl:template >
< xsl:template match=«block» >
< axsl:template match="{.}" >
< fo:block >< axsl:apply-templates/ >< /fo:block >
< /axsl:template >
< /xsl:template >
< /xsl:stylesheet >
Зачем, спрашивается, этот уродливый префикс xsl: перед каждым тегом? Им человека, которому это писать надо, не жалко?
Ах да, многие реализации XSLT, говорят, притормаживают. Вот бы их авторам почитать книжки по оптимизации, точно хуже бы не стало!
Но XML — выглядит мерзко. HTML — нет, так как там много коротких тегов типа [p], много информации хранится в аттрибутах тегов и он смотрится аккуратно, а XML смотрится как каша из тегов. по другому не скажешь.
Смотрите сами:
< xsl:stylesheet
version=«1.0»
xmlns:xsl=«www.w3.org/1999/XSL/Transform»
xmlns:fo=«www.w3.org/1999/XSL/Format»
xmlns:axsl=«www.w3.org/1999/XSL/TransformAlias» >
< xsl:namespace-alias stylesheet-prefix=«axsl» result-prefix=«xsl»/ >
< xsl:template match="/" >
< axsl:stylesheet >
< xsl:apply-templates/ >
< /axsl:stylesheet >
< /xsl:template >
< xsl:template match=«block» >
< axsl:template match="{.}" >
< fo:block >< axsl:apply-templates/ >< /fo:block >
< /axsl:template >
< /xsl:template >
< /xsl:stylesheet >
Зачем, спрашивается, этот уродливый префикс xsl: перед каждым тегом? Им человека, которому это писать надо, не жалко?
Ах да, многие реализации XSLT, говорят, притормаживают. Вот бы их авторам почитать книжки по оптимизации, точно хуже бы не стало!
ну зато парсер сменят потом и все будет работать просто на ура.
Почитайте про namespace в xml, узнаете почему они нужны, и почему xsl: перед каждым тэгом это не мерзость вовсе.
Даже посмотрев на ваш код, можно понять зачем пространства имен нужны, в важем документе используется их аж три штуки.
В xHTML, кстати, тоже используется namespace, только обычно его прописывают для использования по-умолчанию, а так можно сказать что к xHTML будет относится то, что идет после xhtml:
Если лень писать xsl:, можно сократить до x, что некоторые и делают:
Даже посмотрев на ваш код, можно понять зачем пространства имен нужны, в важем документе используется их аж три штуки.
В xHTML, кстати, тоже используется namespace, только обычно его прописывают для использования по-умолчанию, а так можно сказать что к xHTML будет относится то, что идет после xhtml:
xmlns:xhtml="http://www.w3.org/1999/xhtml"
Если лень писать xsl:, можно сократить до x, что некоторые и делают:
xmlns:x="http://www.w3.org/1999/XSL/Transform"
Чистый XSLT сможет прочитать любой человек, знающий XSLT, ваш же шаблон никто кроме вас не прочитает.
а в xslt, кстати, нет проблемы вида «забыл заэкранировать данные». банально потому, что он формирует не «строку текста» а «модель документа», которая уже правильно сериализуется в строку.
в этом основная проблема всяких смартей — они рассматривают выходной документ как строку, совершенно не понимая синтаксис того, что формируют — отсюда и необходимость в костылях типа escape
в этом основная проблема всяких смартей — они рассматривают выходной документ как строку, совершенно не понимая синтаксис того, что формируют — отсюда и необходимость в костылях типа escape
Если вам так не нравятся XML-подобные языки, то и HTML не должен нравиться. Прелесть XSLT как раз в том, что он похож на HTML, тэги в том же стиле, а не как в большинстве шаблонизаторов — не поймешь сразу о чем автор думал когда придумывал во что бы завернуть инструкции своего шаблонизатора.
Были проекты по замене HTML на «более читаемый формат», так как он многим не кажется наглядным, однако их уже никто не помнит, и все пользуются старым добрым HTML.
Были проекты по замене HTML на «более читаемый формат», так как он многим не кажется наглядным, однако их уже никто не помнит, и все пользуются старым добрым HTML.
По-моему. проще грамотно отделить мух от котлет и не использовать текущие шаблонизаторы типа Smarty
Ведь очевидно, что будет быстрее выполняться — str_replace в шаблоне (а если ещё буферы использовать — это же вообще с ума можно сойти), или же простое —
foreach($cContent->posts as $post){
echo $post['title'];
}
Ведь очевидно, что будет быстрее выполняться — str_replace в шаблоне (а если ещё буферы использовать — это же вообще с ума можно сойти), или же простое —
foreach($cContent->posts as $post){
echo $post['title'];
}
спасибо, что смогли тут написать. Очень трудно всю информацию подбить в одно место, а не размазывать по топикам.
ДУПА дал ответ. habrahabr.ru/blogs/php/45651/#comment_1159897
Но лично я считаю что нужно использовать квик (сейчас сайт не доступен, но можно получить копию у меня (пишите в личку)).
а вообще использование таких вложенных структур осуждается, хотя я лично использую
ДУПА дал ответ. habrahabr.ru/blogs/php/45651/#comment_1159897
Но лично я считаю что нужно использовать квик (сейчас сайт не доступен, но можно получить копию у меня (пишите в личку)).
а вообще использование таких вложенных структур осуждается, хотя я лично использую
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум.