программист как правило такой работы бежит

уточнение - наверное все-таки "php-программист" ?

среди "веб2.0/etc-программистов" много хороших профи, пришедших в програминг толстых клиентов на JS с "более серьезных" технологий..

Я сам, будучи программистом, занимаюсь и дизайном, и версткой. То есть на деле я работаю по варианту 1. Однако меня не устраивает внутренний вид получаемых документов. Я стремлюсь к варианту 2, не потому что надо проще, а для того чтобы шаблон отвечал принципам эстетики кода. На strict php далеко не уедешь, а не-strict php или Смарти с php вставками воспринимается также "несъедобно" как программа, написанная без отступов.

третий вариант: верстальщик делает законченный html-документ и вставляет в ключевых местах специальные аттрибуты (семантические метки), а программист уже по ним выцепляет из html-ки нужные ему шаблончики и наполняет DOM данными.

кусок хтмл:

<div id="mmenu">
  <ul>
     <li class="item"><a href="#"><sample>пункт1</sample></a></li>
  </ul>
</div>


псевдокод:

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();



результат:

<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 22.10.07 в 18:42

о, вот dark-demon близок к тому, о чем я думаю, но его вариант в таком виде нежизнеспособен все таки %)

dark-demon говорит о нормальном варианте 2, но как обычно "Баба Яга против!". См. вариант реализации этого способа.

fixxxer, потому и "псевдокод"

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

<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>

этой вёрстки достаточно, чтобы соорудить форму из произвольного числа полей "однострочный текст", "флаг", "выпадающий список" и "небольшой многострочный текст".
Отредактировано dark-demon 23.10.07 в 18:43

dark-demon, а поисковые боты будут тоже JS рендерить?

Dreammaker, поисковые боты формы индексируют?

Люди, люди! Мы здесь о "высоком".
dark-demon -- черная дыра конкретики, постарайтесь не притягиваться к ней.

Dreammaker, поисковым ботам и устаревшим браузерам надо отдавать готовую html вёрстку

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

Strict-PHP - это разработка с уровнем error_reporting(E_STRICT).

Этот уровень репортить всякие крутые нарушения стиля.

Суть разработки в Strict - ни один strict-message не должен остаться в релизе. Ну и варнинги с нотайсами до кучи.

berkut

	типо шоб дизайнер не вызвал случайно фатал еррор

Пусть дизайнер напишет такое {hack}
бгхх. Фатал еррор. Какая ты говоришь идеалогия?))

Я сторонник такого подхода, когда хтмл-верстальщик ("дизайнер") верстает хтмл, вставляя в общий шаблон, скажем, и бутафорскую новость, и закомменченный код шаблона новости, т.е. без данных. Далее программист глядит на образец того, что должно получиться, зацикливает шаблончик новости удобным ему способом, расставляя переменные, и глядит результат. Т.е. все-таки вариант шаблонизатора для программиста...

Плюс подхода - на выходе от верстальщика имеем "чистый" хтмл, который потом можно подвязать к любому шаблонизатору. А это особенною важно, когда исполнитель неизвестен заранее (выбираем фрилансера) или случаются форс-мажоры (текущий разработчик на смарти заболел, в наличии любитель другого шаблонизатора). Еще плюс - бОльшая управляемость отображением, ибо есть всевозможная извращенная логика отображения, которой верстальщику забивать голову совсем необязательно, тем более, в конечном итоге отвечает программист за результат, а не "какой-то там верстальщик".

Я считаю что шаблонами должен заниматься программист иначе приходится сильно ограничивать себя.
А какой шаблонизатор, это зависит от того, что будет в шаблонах.
Нет смысла заменять <?= $var ?> на {$var}, особенно если нет компиляции шаблонов, то это только вредит. Другое дело Smarty и Quicky, которые являются инструментом для программиста и которые делают намного больше простого "echo if foreach", мне удобно использовать именно них, но я не завидую тому, кто будет после меня разбираться в конструкциях а-ля "{message type="info"}....{/message}"
Ну и XSLT, очень удобно, что данные в формате XML, их можно затем сунуть хоть в XSLT, хоть во флеш, хоть в сторонний клиент на С++. Использование exslt делает этот вариант ещё мощнее, ещё один плюс - работа с этим добром в браузере. Но, есть одно большое "НО", очень геморно бороться с валидностью, дп и формат довально громоздкий в плане ресурсов.
dark-demon, а вот мой вариант для форм на смарти, а сама описание формы хранится в XML

<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>

dark-demon по поводу селекта, item="field" хранит информацию о текущем поле type, name, class, validate и прочее.

{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}


__________________
Keep It Simple, Stupid. Отредактировано AmdY 27.10.07 в 18:36

Говорю как человек измученный нарзаном.
Шаблонизатор надо юзать тот который будет удобен тем людям которые заняты в проекте. Если программисту нравится что клиенты его будут насиловать в мозг при необходимости вывести данные в две колонки, а не в три, - пусть пишет скрипт view а затем использует блочный шаблонизатор чтоб дать возможность редактирования html (Blitz). Если же хочет вынести всю логику представления в шаблон вместо отдельного скрипта - php native, если при этом хочет облегчить жизнь верстальщику, получить доп. инструменты и возможность настройки безопасности (чтоб бекдоров не навставляли) - Quicky.
Необходимо понимать что разница между Blitz и Quicky лишь в том что в Blitz мы сначала всю полноту фантазии выражаем в скрипте, а потом прогоняем через набор циклов и получаем html.
Если верстальщик может залезть в скрипт и исправить там то ему ничто не помешает исправить шаблон Quicky, иначе - он будет долбить программиста чтоб тот исправил, и теряется одно из главных достоинств шаблонизатора - сохранение девственности мозга программера. На правах рекламы, Quicky поддерживает синтаксис blitz и в одном проекте я использовал гибридную схему (по желанию заказчика) т.е. каждый шаблон представлял собой сначала обработку входных данных и генерацию информации для вывода методом аля блитз, а далее шел шаблон с синтаксисом блитза.
Таким образом если человек в состоянии исправить логику - пусть правит, если не в состоянии - пусть правит html и дергает за рукав того кто может (не меня), а мне на этих людей класть с прибором т.к. я в скрипте проассигнил данные и забыл. Могут вдруг передумать и переписать шаблон на чистый Quicky без предварительной обработки - я буду не нужен.
К XSLT и прочему бесовству отношусь негативно т.к. это опять же требует от верстальщика программерских знаний и не только, да еще и сильно вредит гибкости.

Кстати, использую "компоненты" и мне нравится т.к. часто нужно вызвать какой-то обособленый скрипт или не вызвать (это решается непосредственно в шаблоне), а включать/выключать подгрузку PHP-кода того или иного модуля было бы неудобно где-то отдельно от шаблона.
А также, что приятно, использую свои нововведения по части управления компиляцией из шаблона
Отредактировано WP 27.10.07 в 04:08

	Quicky поддерживает синтаксис blitz

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

-~{}~ 27.10.07 12:50:

в смысле - квики генерил не пхп-страницу, а пхп-страницу плюс шаблон для блиц?!

WP
Даааа. А использование "плагинов", "компонентов" и прочей хрени не требует программерских знаний. Особенно если поведение этого "плагина" нужно немного поменять....
Ну-ну...
ПС. Я конечно понимаю, ты написал опенсоурс, но зачем кричать о нём по всему форуму и сравнивать ? (К этой теме это не относится)

фигасе, xslt вредит гибкости? 8-[___]

AmdY, в твоём шаблоне верстальщик теряет контроль над тем, как будут выводиться инпуты различных типов. например, может потребоваться select обернуть в специальный div, чтобы обрезать убогие псевдо-3д бордюры в ие.

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, а преобразователь из проассигненных данных в итерации хранить в шаблоне.