Chaser, ну в общем примерно это мне и представляется оптимальным вариантом. Вроде о том и писал, как это сделать.
Chaser Рано или поздно столкнёшься с ситуацией что без PHP никак ни сделать. Не зря в самом "крутом" шаблонизаторе Smarty есть тег {php}{/php} - мне что-то слишком часто приходилось его использовать. Рано или поздно вы поймёте что всякие шабонизаторы, написанные на PHP не только тормозят, но ещё вас и ограничивают. Есть такие понятия как логика приложения и логика шаблона. Просто голым PHP решаются обе задачи сразу - легко, быстро и эффективно. А если делать свой шаблонизатор или использовать Smarty like - медленно и не так удобно и просто как кажется на первый взгляд. Видел проэкты, где народ на smarty прилепливал по 50-60 собственных плагинов, потому что не могли решить проблему чисто Smarty тегами. Идиотизм да и только, без кешера PHP кода такое работать просто не могло, да и с ним тормозило до жути.
нет никакой "логики шаблона", есть "логика отображения"(которая, кстати, является составной частью "логики приложения"), которой в шаблоне делать нечего. шаблон хслт - это лекало - набор простых кривых из которых формируется чертёж. шаблон смарти - это законченный механизм для рисования чертежа, одного конкретного чертежа. если нужно нарисовать другой чертёж - извольте пересобирать весь механизм. а вообще, мне нравится эта эволюция... всем была хороша обработка текста в перле, да вот только шаблонизатор из него был фиговый. написали для него пхп и стали тянуть всю логику в пхп, пока наконец не стали вообще всё делать на пхп. но, блин, всё-равно фиговый из пхп шаблонизатор - написали смарти и стали тянуть логику на смарти. скоро смарти будет самостоятельным языком програмирования... и для него опять напишут шаблонизатор...
Почему именно для смарти? Почему не для Blitz? И кто мешает использовать кирпичики шаблонов смарти в других шаблонах смарти?
проблема не в реюзинге и обособлении шаблонов, а в реюзинге и обособлении логики. например, распространённая ошибка дублирования логики: скрипт вытягивает данные из базы и отдаёт шаблонизатору, шаблон вытягивает эти же данные из переданной шаблонизатору структуры. получается, что решение тянуть или не тянуть эти данные, принимается в двух местах, что приводит к четырём вариантам поведения: 1. и скрипт и шаблон тянут. ок, данные доходят до пользователя. 2. и скрипт и шаблон не тянут. ок, данные никуда не идут. 3. скрипт тянет, а шаблон - нет. пустая трата ресурсов. 4. шаблон тянет, а скрипт - нет. ошибка. не редко - фатальная. в лучшем случае - её можно игнорировать. так вот, продуктивными являются только первые два варианта. реализуются они двумя способами: 1. пассивный шаблон - шаблон полностью управляемый поступающими данными. он не делает никаких выборок. если данные пришли и они определённого типа - будет использован соответствующий шаблон. из распространённых шаблонизаторов пассивные шаблоны позволяет реализовать xslt. 2. активный шаблон - шаблон, который абсолютно ничего не принимает на вход, но в нужных местах он запрашивает данные напрямую у модели. легендарная пхпшная лапша - это и есть те самые "активные шаблоны". использование смарти, пхп и им подобных в качестве шаблонизаторов приводит к тому, что на каждый чих приходится делать однотипные правки минимум в двух местах.
И? Меня чем убивает XTemplate, так это тем, что помимо основного Controller'а, обрабатывающего запрос, для View нужен свой Controller, который бы компоновал вывод. То есть получается, что программист так или иначе начинает задумываться об отображении. В этом плюс у Smarty. XSLT лишён этого недостатка, но вот Data->XML->Data'+XSL->XHTML... Меня такая цепочка не очень радует.
А что если в один прекрасный момент я захочу поменять число столбцов? Придёться лезть в код. Выходит, что программист задаёт то, как таблица должна выглядеть на экране.
а тот, кто пишет циклы и ветвления на смарти - тот типа не программист? правильная цепочка такая: data->[serializer]->xml->[xslt]->html
Думаю, нет. Да это число будет в такой же лапше находиться. И делать это придётся программисту, а не верстальщику. "Вася, мы решили дизайн немножко поменять, залезь в код, поменяй нам там плиз число..." - абсурдно звучит, имхо.
тогда кто такой "прораммист"? и чем он отличается от "верстальщика"? "Вася, мы решили дизайн немножко поменять, залезь в код, поменяй нам там плиз число..." - вполне нормальная ситуация. более того, при изменении числа столбцов потребуется также изменить и число получаемых из базы строк.
Программист это тот, кто проектирует структуру базы данных(хотя в последнее время это отдельная специальность), как оптимальнее обрабатывать запросы от пользователя и т.д. Дизайнер - это тот, кто думает, как бы эффективнее подать информацию на сайте(не только из базы данных, но и о имидже компании и т.д.), верстальщик - тот, кто реализовывает задумки дизайнера в HTML. Так как в отображении чего-либо на экране часто встречаются повторяющиеся фрагменты, то верстальщику можно и нужно работать с циклами. Условия в "идеальном" варианте, когда на каждый случай свой шаблон, не присутствуют, но, как мера борьбы с повторяющимся кодом вводятся различные условия. Да и сложно найти человека, который бы не понимал условий. Что ж теперь, всех программистами называть?
Я выше постил пример движка с шаблонизатором, где прекрасно работает принцип - если модуль данных не выбрал, то в шаблон просто выведет что данных нету. И это ПРАВИЛЬНОЕ поведение шаблона, потому что он может выводить не только что данных нету, а например другой блок какой-то. Логика отображения не должна зависить от логики приложения. Логика отображения это к примеру когда надо раскрасить таблицу в полоску, что-бы визуально отличать одну строку от другого. Это должен делать именно шаблон. Задача приложения - предоставить шаблону данные, а как само приложение уже работает - не важно вообще. Так же приложению обсалютно всёравно как работает шаблон и что за технология там используется - Smarty, Savant, XLST, PHP, теги реплейсом и.т.д. - оно просто отдаёт данные через интерфейс. В итоге у вас две независимые части, которые общаются через какой-то вами определённый интерфейс и вы можете их совмещать как хотите. Вот так это должно работать.
всех, кто пишет программы логично называть программистами. насколько я понял, под верстальщиком ты подразумеваешь фронт-энд программиста, настолько трудолюбивого, что он готов отказаться от отделения вёрски от програмного кода и писать их вперемешку. хотите рсс? пожалуйста, те же самые условия и циклы, но с другими фрикадельками. хотите пда-версию? да нет проблем, скопипастим ещё раз и разварим мясо как следует. что? вы хотите везде поменять вот это условие??? а-а-а! ну да, а задача ПРОГРАММИСТА - всего-лишь сформировать правильный sql-запрос... ой, это же задача дба... что же остаётся? проверка параметров формы? и вопрос тут не в том, кто что не понимает, а в том, что логические конструкции языка программирования в перемешку с инородными вставками языка разметки трудно писать, трудно воспринимать и очень трудно редактировать. это выливается в дополнительное время на совершение этих действий, повышение уровня ошибок, общую неудовлетворённость процессом работы.
sword dancer Верстальщик это тот человек, который пишет HTML с CSS код. По сути есть два варианта: 1). Верстает HTML и CSS и отдаёт программисту, который уже навешивает необходимые вставки. По сути не продвинутый верстальшик, потому-что любое серьёзное изменение дизайна/вывода требует участие программиста (при этом данные сами по себе не меняются). 2). Программист делает сам простейший шаблон, в котором есть все вставки и вывод данных. Верстальшик берёт эту заготовку и обвешивает её нормальным HTML кодом со всеми стилями. При изменении дизайна/вывода он прекрасно поменяет шаблон сам легко и быстро. Я работал именно с таким верстальшиком - кроме HTML, СSS и немного JS он ничё больше не знал, но это ему не мешало работать с шаблонами с PHP вставками, причём менял он частенько всё ног на голову без участия программистов.
PHP: // здесь был темплейт modules/menu/templates/left_common_menu.htm из архива движка предоставленного Psih'ом выше. хорошая иллюстрация того, как делать не надо.
Да с какого перепугу? Разумеется в реальном контроллере в самом начале будет написано что-то типа: define('NUM_COLS', 3);
любые серьёзные изменения требуют участия и программиста, и верстальщика, и дизайнера, и менеджера, и редактора, и бог ещё знает кого. вопрос лишь в том, сколько это составит суммарно геморроя. вариант "избавим программиста от собственно программирования" - интересный, но не продуктивный.
sword dancer Никто не идиален. К тому-же была своя логика почему сделали именно так, а не через базу данных с таблицой пунктов меню и.т.д. или более компактно. В smarty это выглядело-бы ещё хуже
Да не бывает ситуации, чтобы программист мог не задумываться об отображении. Клиентская часть в современных веб-приложениях достаточно сложна. Один AJAX чего стоит. И тенденция такая, что веб-приложения по сложности интерфейса скоро мало будут отличаться от GUI. Так что это все розовые мечты, чтоб программист только одними SQL запросами опереровал. Никакой верстальщик не привяжет сам мало мальски сложный интерфейс к бизнес-логике приложения. Максимум сможет подправить шаблоны. А для этого шаблоны должны являться максимально близкими к HTML, а не быть PHP/Smarty лапшой.
sword dancer Потому что было так удобно, потому что проэкт был крайне специфичен, потому что сделали минимум логики и циклов, без лишних запросов. Просто поставили проверки и подстановку нужных данных в шаблон, вот и всё. Быстро и просто. Сам я по сути не вижу проблемы в этом шаблоне. HTML с некоторыми условиями, ничё сложного.