-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Для кого мы делаем шаблоны?
- Автор темы Фанат
- Дата начала
С.
Продвинутый новичок
Я сам, будучи программистом, занимаюсь и дизайном, и версткой. То есть на деле я работаю по варианту 1. Однако меня не устраивает внутренний вид получаемых документов. Я стремлюсь к варианту 2, не потому что надо проще, а для того чтобы шаблон отвечал принципам эстетики кода. На strict php далеко не уедешь, а не-strict php или Смарти с php вставками воспринимается также "несъедобно" как программа, написанная без отступов.
dark-demon
d(^-^)b
третий вариант: верстальщик делает законченный html-документ и вставляет в ключевых местах специальные аттрибуты (семантические метки), а программист уже по ним выцепляет из html-ки нужные ему шаблончики и наполняет DOM данными.
кусок хтмл:
псевдокод:
результат:
но это уже рассчитано на совсем мифического верстальщика и очень трудолюбивого программиста 
кусок хтмл:
PHP:
<div id="mmenu">
<ul>
<li class="item"><a href="#"><sample>пункт1</sample></a></li>
</ul>
</div>
PHP:
var menu= doc.xpath( "//*[@id='mmenu']" );
var curitem= menu.xpath( "//*[@class='item']" );
var menuitem= curitem.clone(); // шблон вывода одного пункта меню.
if( data ) for( item in menudata ){
var newitem= menuitem.clone();
newitem.xpath( '//sample' )= item.title;
newitem.xpath( '//@href' )= item.uri;
curitem.insertAfter( newitem );
curitem= newitem;
} else menu.die();результат:
PHP:
<div id="mmenu">
<ul>
<li class="item"><a href="/abc/">щёлкни меня!</a></li>
<li class="item"><a href="/dfe/">нет, меня!</a></li>
<li class="item"><a href="/fgh/">и меня! и меня!</a></li>
<li class="item"><a href="/ijk/">прищёлкни себя!</a></li>
</ul>
</div>
dark-demon
d(^-^)b
fixxxer, потому и "псевдокод"
С., нет, это не этот способ. ты зачем-то заменяешь угловые скобочки на вопросительные угловые скобочки, излишне плодишь тэги, поощряешь дедовщину (старшие браться влияют на младших), делаешь шаблоны активными ("шаблон лезет за данными", а "не данные впрыскиваются в шаблон"), предоставляешь программисту не набор вложенных шаблонов, а конечную вёрстку, не предполагающую расширение (добавление полей, например).
у тебя - как раз тот самый "вариант номер два". третий вариант выглядил бы так:
этой вёрстки достаточно, чтобы соорудить форму из произвольного числа полей "однострочный текст", "флаг", "выпадающий список" и "небольшой многострочный текст".
С., нет, это не этот способ. ты зачем-то заменяешь угловые скобочки на вопросительные угловые скобочки, излишне плодишь тэги, поощряешь дедовщину (старшие браться влияют на младших), делаешь шаблоны активными ("шаблон лезет за данными", а "не данные впрыскиваются в шаблон"), предоставляешь программисту не набор вложенных шаблонов, а конечную вёрстку, не предполагающую расширение (добавление полей, например).
у тебя - как раз тот самый "вариант номер два". третий вариант выглядил бы так:
PHP:
<form method=post id="myForm" class="x-form-items">
<label>
<sample>Label1:</sample>
<input name="Element1" type="text" class="x-field" />
</label>
<label>
<sample>Label2:</sample>
<input name="Element2" type="checkbox" value="yes" class="x-flag" />
</label>
<label>
<sample>Label3:</sample>
<select name="Element3" class="x-select"></select>
</label>
<label>
<sample>Label4:</sample>
<textarea name="Element4" class="x-smalltext"></textarea>
</label>
</form>
Dreammaker
***=Ф=***
dark-demon, а поисковые боты будут тоже JS рендерить? 
dark-demon
d(^-^)b
Dreammaker, поисковым ботам и устаревшим браузерам надо отдавать готовую html вёрстку
berkut
Новичок
чёрт, подскажите ламеру, что такое strict-php? сознательное использование только определённых конструкций или же "програмное" ограничение на допустимые к использованию конструкции?? если второе - то как это реализуется без охренительного парсера, если первое - то как-же насчёт идеологии смарти, что можно "разграничивать" права на использование функций(типо шоб дизайнер не вызвал случайно фатал еррор)?
Silex
unitecsys
Я сторонник такого подхода, когда хтмл-верстальщик ("дизайнер") верстает хтмл, вставляя в общий шаблон, скажем, и бутафорскую новость, и закомменченный код шаблона новости, т.е. без данных. Далее программист глядит на образец того, что должно получиться, зацикливает шаблончик новости удобным ему способом, расставляя переменные, и глядит результат. Т.е. все-таки вариант шаблонизатора для программиста...
Плюс подхода - на выходе от верстальщика имеем "чистый" хтмл, который потом можно подвязать к любому шаблонизатору. А это особенною важно, когда исполнитель неизвестен заранее (выбираем фрилансера) или случаются форс-мажоры (текущий разработчик на смарти заболел, в наличии любитель другого шаблонизатора). Еще плюс - бОльшая управляемость отображением, ибо есть всевозможная извращенная логика отображения, которой верстальщику забивать голову совсем необязательно, тем более, в конечном итоге отвечает программист за результат, а не "какой-то там верстальщик".
Плюс подхода - на выходе от верстальщика имеем "чистый" хтмл, который потом можно подвязать к любому шаблонизатору. А это особенною важно, когда исполнитель неизвестен заранее (выбираем фрилансера) или случаются форс-мажоры (текущий разработчик на смарти заболел, в наличии любитель другого шаблонизатора). Еще плюс - бОльшая управляемость отображением, ибо есть всевозможная извращенная логика отображения, которой верстальщику забивать голову совсем необязательно, тем более, в конечном итоге отвечает программист за результат, а не "какой-то там верстальщик".
Я считаю что шаблонами должен заниматься программист иначе приходится сильно ограничивать себя.
А какой шаблонизатор, это зависит от того, что будет в шаблонах.
Нет смысла заменять <?= $var ?> на {$var}, особенно если нет компиляции шаблонов, то это только вредит. Другое дело Smarty и Quicky, которые являются инструментом для программиста и которые делают намного больше простого "echo if foreach", мне удобно использовать именно них, но я не завидую тому, кто будет после меня разбираться в конструкциях а-ля "{message type="info"}....{/message}"
Ну и XSLT, очень удобно, что данные в формате XML, их можно затем сунуть хоть в XSLT, хоть во флеш, хоть в сторонний клиент на С++. Использование exslt делает этот вариант ещё мощнее, ещё один плюс - работа с этим добром в браузере. Но, есть одно большое "НО", очень геморно бороться с валидностью, дп и формат довально громоздкий в плане ресурсов.
dark-demon, а вот мой вариант для форм на смарти, а сама описание формы хранится в XML
dark-demon по поводу селекта, item="field" хранит информацию о текущем поле type, name, class, validate и прочее.
А какой шаблонизатор, это зависит от того, что будет в шаблонах.
Нет смысла заменять <?= $var ?> на {$var}, особенно если нет компиляции шаблонов, то это только вредит. Другое дело Smarty и Quicky, которые являются инструментом для программиста и которые делают намного больше простого "echo if foreach", мне удобно использовать именно них, но я не завидую тому, кто будет после меня разбираться в конструкциях а-ля "{message type="info"}....{/message}"
Ну и XSLT, очень удобно, что данные в формате XML, их можно затем сунуть хоть в XSLT, хоть во флеш, хоть в сторонний клиент на С++. Использование exslt делает этот вариант ещё мощнее, ещё один плюс - работа с этим добром в браузере. Но, есть одно большое "НО", очень геморно бороться с валидностью, дп и формат довально громоздкий в плане ресурсов.
dark-demon, а вот мой вариант для форм на смарти, а сама описание формы хранится в XML
PHP:
<div class="formDiv">
{if $form->formValidate}
<div class="error_message">
{foreach from=$form->formValidate item="v"}
{$v.text}
{/foreach}
</div>
{/if}
<div class="formFields">
{$form->begin()}
{foreach from=$form->formFields item="field"}
<div class="formCaption">{if $form->getCaption()}{$form->getCaption()}</div>{/if}
<div class="formField">{$form->next()}</div>
{/foreach}
{$form->end()}
</div>
</div>
PHP:
{foreach from=$form->formFields item="field"}
<div class="formCaption">{if $form->getCaption()}{$form->getCaption()}</div>{/if}
{if $field->type=='select'}
<div class="formFieldSelect">{if $field->validate}<span class="red bold">*</span>{/if}{$form->next()}</div>
{else}
<div class="formField">{$form->next()}</div>
{/if}
{/foreach}WP
^_^
Говорю как человек измученный нарзаном.
Шаблонизатор надо юзать тот который будет удобен тем людям которые заняты в проекте. Если программисту нравится что клиенты его будут насиловать в мозг при необходимости вывести данные в две колонки, а не в три, - пусть пишет скрипт view а затем использует блочный шаблонизатор чтоб дать возможность редактирования html (Blitz). Если же хочет вынести всю логику представления в шаблон вместо отдельного скрипта - php native, если при этом хочет облегчить жизнь верстальщику, получить доп. инструменты и возможность настройки безопасности (чтоб бекдоров не навставляли) - Quicky.
Необходимо понимать что разница между Blitz и Quicky лишь в том что в Blitz мы сначала всю полноту фантазии выражаем в скрипте, а потом прогоняем через набор циклов и получаем html.
Если верстальщик может залезть в скрипт и исправить там то ему ничто не помешает исправить шаблон Quicky, иначе - он будет долбить программиста чтоб тот исправил, и теряется одно из главных достоинств шаблонизатора - сохранение девственности мозга программера. На правах рекламы, Quicky поддерживает синтаксис blitz и в одном проекте я использовал гибридную схему (по желанию заказчика) т.е. каждый шаблон представлял собой сначала обработку входных данных и генерацию информации для вывода методом аля блитз, а далее шел шаблон с синтаксисом блитза.
Таким образом если человек в состоянии исправить логику - пусть правит, если не в состоянии - пусть правит html и дергает за рукав того кто может (не меня), а мне на этих людей класть с прибором т.к. я в скрипте проассигнил данные и забыл. Могут вдруг передумать и переписать шаблон на чистый Quicky без предварительной обработки - я буду не нужен.
К XSLT и прочему бесовству отношусь негативно т.к. это опять же требует от верстальщика программерских знаний и не только, да еще и сильно вредит гибкости.
Кстати, использую "компоненты" и мне нравится т.к. часто нужно вызвать какой-то обособленый скрипт или не вызвать (это решается непосредственно в шаблоне), а включать/выключать подгрузку PHP-кода того или иного модуля было бы неудобно где-то отдельно от шаблона.
А также, что приятно, использую свои нововведения по части управления компиляцией из шаблона
Шаблонизатор надо юзать тот который будет удобен тем людям которые заняты в проекте. Если программисту нравится что клиенты его будут насиловать в мозг при необходимости вывести данные в две колонки, а не в три, - пусть пишет скрипт view а затем использует блочный шаблонизатор чтоб дать возможность редактирования html (Blitz). Если же хочет вынести всю логику представления в шаблон вместо отдельного скрипта - php native, если при этом хочет облегчить жизнь верстальщику, получить доп. инструменты и возможность настройки безопасности (чтоб бекдоров не навставляли) - Quicky.
Необходимо понимать что разница между Blitz и Quicky лишь в том что в Blitz мы сначала всю полноту фантазии выражаем в скрипте, а потом прогоняем через набор циклов и получаем html.
Если верстальщик может залезть в скрипт и исправить там то ему ничто не помешает исправить шаблон Quicky, иначе - он будет долбить программиста чтоб тот исправил, и теряется одно из главных достоинств шаблонизатора - сохранение девственности мозга программера. На правах рекламы, Quicky поддерживает синтаксис blitz и в одном проекте я использовал гибридную схему (по желанию заказчика) т.е. каждый шаблон представлял собой сначала обработку входных данных и генерацию информации для вывода методом аля блитз, а далее шел шаблон с синтаксисом блитза.
Таким образом если человек в состоянии исправить логику - пусть правит, если не в состоянии - пусть правит html и дергает за рукав того кто может (не меня), а мне на этих людей класть с прибором т.к. я в скрипте проассигнил данные и забыл. Могут вдруг передумать и переписать шаблон на чистый Quicky без предварительной обработки - я буду не нужен.
К XSLT и прочему бесовству отношусь негативно т.к. это опять же требует от верстальщика программерских знаний и не только, да еще и сильно вредит гибкости.
Кстати, использую "компоненты" и мне нравится т.к. часто нужно вызвать какой-то обособленый скрипт или не вызвать (это решается непосредственно в шаблоне), а включать/выключать подгрузку PHP-кода того или иного модуля было бы неудобно где-то отдельно от шаблона.
А также, что приятно, использую свои нововведения по части управления компиляцией из шаблона
cDLEON
Онанист РНРСlub
WP
Даааа. А использование "плагинов", "компонентов" и прочей хрени не требует программерских знаний. Особенно если поведение этого "плагина" нужно немного поменять....
Ну-ну...
ПС. Я конечно понимаю, ты написал опенсоурс, но зачем кричать о нём по всему форуму и сравнивать ? (К этой теме это не относится)
Даааа. А использование "плагинов", "компонентов" и прочей хрени не требует программерских знаний. Особенно если поведение этого "плагина" нужно немного поменять....
Ну-ну...
ПС. Я конечно понимаю, ты написал опенсоурс, но зачем кричать о нём по всему форуму и сравнивать ? (К этой теме это не относится)
dark-demon
d(^-^)b
фигасе, xslt вредит гибкости? 8-[___]
AmdY, в твоём шаблоне верстальщик теряет контроль над тем, как будут выводиться инпуты различных типов. например, может потребоваться select обернуть в специальный div, чтобы обрезать убогие псевдо-3д бордюры в ие.
AmdY, в твоём шаблоне верстальщик теряет контроль над тем, как будут выводиться инпуты различных типов. например, может потребоваться select обернуть в специальный div, чтобы обрезать убогие псевдо-3д бордюры в ие.
WP
^_^
cDLEON
Дык смотри, у меня компонент module_load, в шаблоне пишу {module_load name='news' as_module=1}
И в том месте страницы появляется модуль новостей (блоком или страницей), при этом module_load инклюдит нужный PHP-скрипт, тот работает с СУБД, ассигнит данные и показывает шаблон news.tpl. При этом верстальщик легко поймет конструкцию и залезет в news.tpl если надо.
Фaнат
Поддерживает в том плане что синтаксис блитз компилируется в PHP-код, и можно использовать как замену блитза где нет возможности поставить модуль (класс-эмулятор API Blitz'а прилагается).
А была использована следующая схема, сначала в шаблоне идет обработка проассигненых данных и перевод их в набор итераций, а затем идет текст шаблона аля блитз где эти итерации обрабатываются. Главное - программист самого скрипта не участвует.
Для скорости (правда не знаю что будет быстрее, Blitz или скомпилированный код в for'ы (+ eAccelerator)) - можно отдавать парсинг шаблона самому Blitz, а преобразователь из проассигненных данных в итерации хранить в шаблоне.
Дык смотри, у меня компонент module_load, в шаблоне пишу {module_load name='news' as_module=1}
И в том месте страницы появляется модуль новостей (блоком или страницей), при этом module_load инклюдит нужный PHP-скрипт, тот работает с СУБД, ассигнит данные и показывает шаблон news.tpl. При этом верстальщик легко поймет конструкцию и залезет в news.tpl если надо.
Фaнат
Поддерживает в том плане что синтаксис блитз компилируется в PHP-код, и можно использовать как замену блитза где нет возможности поставить модуль (класс-эмулятор API Blitz'а прилагается).
А была использована следующая схема, сначала в шаблоне идет обработка проассигненых данных и перевод их в набор итераций, а затем идет текст шаблона аля блитз где эти итерации обрабатываются. Главное - программист самого скрипта не участвует.
Для скорости (правда не знаю что будет быстрее, Blitz или скомпилированный код в for'ы (+ eAccelerator)) - можно отдавать парсинг шаблона самому Blitz, а преобразователь из проассигненных данных в итерации хранить в шаблоне.