Drupal 5.0 вышел!

> а innerHTML у такого id'шнутого h1 можно переписать

Разумеется.

> даже если можно то выглядит это все как то коряво, есть div как аналог холста или лейбла в GUI фреймворках, зачем городить переопределения тегов ?

Как минимум - для поисковых движков. А вообще - откройте для себя WAI WCAG.

> т.е. "представление" находится в "данных" о_0 ?

да, представление это тоже "данные". Которые тоже меняются со временем. На самом деле использование БД как хранилище шаблонов довольно удобно, при наличии грамотно построенного интерфейса к БД. Попутно это увеличивет security системы в целом.

+1

Предпочитаю cmsmadesimple. Довольно удобная обертка вокруг Smarty.

а в чем собственно проблема с div'ами ? выглядят они более унифицированно чем определения классов и стилей для каждого тега, на полноценную верстку web всеравно не тянет, а так получается более зумльподобно

Хороший, удобный, гибкий и мощный движок. Мне нравится :)

Ой спасибо не знал. А вот тебе http://devzone.zend.com/node/view/id/1302. Это как на zend.com предлагают юзать XLS и XML, вот спасибо, нафиг мне такое щастье надо.

> а в чем собственно проблема с div'ами ?

Отключите CSS и поймёте, как div'ные странички воспринимаются поисковиками.

> на полноценную верстку web всеравно не тянет

Вы о чём? Полноценная - это в QuarkXpress'е?

Вообще, div это хороший тон. Разметка дивами, определение классов для div и потом присваивание стилей для этих div'ов в css'e

> да, представление это тоже "данные". Которые тоже меняются со временем.

Движок - тоже данные. И тоже меняется со временем.

> На самом деле использование БД как хранилище шаблонов довольно удобно, при наличии грамотно построенного интерфейса к БД.

Ну, бывает. Это уж кому что удобно.

> Попутно это увеличивет security системы в целом.

Как минимум спорно.

а запихивает эти данные в базу и изменяет код ? ну это всеравно что лупить через echo, print и т.п. или вот допустим бд упала шаблон на фс + скрипт сможет вякнуть мол "заходите позже", а кто достанет соотв шаблон из упавшей бд ? и как быть с такими удобствами как подстветка синтаксиса, автодополнение и пр. ? много редакторов смогут запросить код шаблона, отобразить и закоммитить обратно ? такой подход удобен для шаблона мелкого модуля (в котором кроме количества колонок или цвета конпки ничего менять не надо) но универсальным он ниразу не является.

> Вообще, div это хороший тон. Разметка дивами, определение классов для div и потом присваивание стилей для этих div'ов в css'e

Хороший тон? Вот это - http://www.w3.org/TR/WCAG10/ - хороший тон.

> Хороший тон? Вот это - http://www.w3.org/TR/WCAG10/ - хороший тон.

Что-то не вижу ничего про то, что использование div это плохой тон и вообще неправильно.

> Отключите CSS и поймёте, как div'ные странички воспринимаются поисковиками.

имеются ввиду кэшированные этими поисковиками страницы ? только что отключил для одного сайта, браузер просто построил все элементы в одну колонку

> Вы о чём? Полноценная - это в QuarkXpress'е?

о латехе и других языках для людей, в html смотрят только верстальщики/программисты и это их дело как лучше все это должно быть, очень много пользователей не знают как поменять кодировку в браузере, им нет разницы дивами сверстана страница или нет

> Что-то не вижу ничего про то, что использование div это плохой тон и вообще неправильно.

Guideline 3. Use markup and style sheets and do so properly.

3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
3.6 Mark up lists and list items properly. [Priority 2]
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2]

> > Отключите CSS и поймёте, как div'ные странички воспринимаются поисковиками.

> имеются ввиду кэшированные этими поисковиками страницы ? только что отключил для одного сайта, браузер просто построил все элементы в одну колонку

Значит, структура документа без CSS не видна. Это считается дурным тоном.

> в html смотрят только верстальщики/программисты и это их дело как лучше все это должно быть, очень много пользователей не знают как поменять кодировку в браузере, им нет разницы дивами сверстана страница или нет

А роботам - не всё равно. Googlebot не различает <div> и <div class="header">, зато прекрасно отличает <div> от <h1>. Вообще говоря, у веб-страниц бывает много других применений, кроме просмотра на большом цветном экране живым человеком.

видимо мы спорим о разных вебах, я - с точки зрения аяксовых приложений и порталов с кучей сервисов, вы, похоже, про хтмл верстаемый практически вручную. В этом нет необходимости документацию и ей подобное нормально верстают утилиты *2html

>> да, представление это тоже "данные". Которые тоже меняются со временем.

> Движок - тоже данные. И тоже меняется со временем.

Ну если все устраивает, зачем менять движок? Я вот менял движок фактически один раз - когда переписывал его с PHP3 на PHP4 и делал версию на Perl. Это было довольно давно.

>> На самом деле использование БД как хранилище шаблонов довольно удобно, при наличии грамотно построенного интерфейса к БД.

> Ну, бывает. Это уж кому что удобно.

Это удобно заказчикам прежде всего, они сами могут менять шаблоны и контент когда захотят и как захотят. Но к серверу у них доступа нету, кроме http. Это также удобно техсуппорту, с которых снимается забота об обновлении контента. Кому это может быть неудобно ?

>> Попутно это увеличивет security системы в целом.

> Как минимум спорно.

Это не спорно, это так и есть. FTP доступ для обновления сайта не нужен совсем, а это практически единственное, что еще разрешает передавать пароли в открытом виде.

> а запихивает эти данные в базу и изменяет код ? ну это всеравно что лупить через echo, print и т.п. или вот допустим бд упала шаблон на фс + скрипт сможет вякнуть мол "заходите позже", а кто достанет соотв шаблон из упавшей бд ? и как быть с такими удобствами как подстветка синтаксиса, автодополнение и пр. ? много редакторов смогут запросить код шаблона, отобразить и закоммитить обратно ? такой подход удобен для шаблона мелкого модуля (в котором кроме количества колонок или цвета конпки ничего менять не надо) но универсальным он ниразу не является.

Вообще целиком шаблоны меняются довольно редко, а вот части их (области, доступные для редактирования) - часто, в зависимости от смены контента. И для редактирования этих частей есть встроенный в веб морду WYSIWYG редактор. Если база упала, выводится просто аварийная страница (статическая). И все.

>Впервые встречаю вменяемого программиста на пхп. Выражаю свою почтение. Возможно вам стоит задуматься, что ЛОР это не то место, где стоит кому-то что-то доказывать - бесполезно.

Увы Вам, я, к счастью, не программист PHP.

> > > Ну чем, чем именно? > > Тем, что он выполняется в контексте PHP, а не как шаблон с ограниченной функциональностью.

>Ещё раз спрашиваю: что в этом "небезопасного"?

Тем, что include(.....) внутри шаблона это _элемент_верстки_. Допускать _возможность_ интерпретации _кода_ PHP внутри _элемента_верстки_ недопустимо.

Это ровно тоже самое, что давать всем юзерам на машине логин root и просить быть хорошими, не трогать то, что им не положено по статусу.

Вдобавок, это еще и медленно, потому, что нет возможности закешировать шаблон в памяти в виде байткода. Следовательно, при каждом запросе будет производиться интерпретация шаблона, в чем нет необходимости, если шаблон не менялся.

Касаемо очень и не очень платных проприетарных поделий фирмы Zend (Optimizer/Accelerator), то они, в зависимости от фазы Луны и версий PHP и OS, увы, не всегда работают под большой нагрузкой и с разными php extensions.

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

stellar, вот такой вопрос человеку, считающему что веб-сервер должен иметь права на директории с кодом сайта read only: а кеширование резульататов выполнения шаблонов кто, как и куда будет делать ?

> самый продвинутый web-визивиг, который я видел (битриксный) позволял только редактировать позицию и некоторые параметры модуля для остольного предполагалось редактирование кода, сам шаблон тут практически непричем (т.е. заливка, фоновая картика, вид рамки).

шаблон через WYSIWYG не редактируется, это просто не нужно - в случае смены шаблонов (дизайна сайта, например), просто HTML код копипастится в веб редактор или еще куда и потом назад. Это редко бывает все равно. А встроенный WYSIWYG редактор для контента только используется, там более, что для редактирование текста практически ничего большего не нужно. Правда буду прикручивать вставку картинок еще.

>stellar, вот такой вопрос человеку, считающему что веб-сервер должен иметь права на директории с кодом сайта read only: а кеширование резульататов выполнения шаблонов кто, как и куда будет делать ?

Я не stellar, но чем вам не нравиться сделать одну директорию с правом записи и туда писать (аки сделано в smarty)? Или изображения/pdf-файлы/..., загруженные пользователем вы в базе храните? :)

>а innerHTML у такого id'шнутого h1 можно переписать, даже если можно то выглядит это все как то коряво, есть div как аналог холста или лейбла в GUI фреймворках, зачем городить переопределения тегов ?

innerHTML вообще не кошерно использовать. Потегово создавать вложенный контент - наше всйо )

ЛОР теперь филиал phpclub :)

>stellar, вот такой вопрос человеку, считающему что веб-сервер должен иметь права на директории с кодом сайта read only: а кеширование резульататов выполнения шаблонов кто, как и куда будет делать ?

Либо в оперативную память, если ее хватает, либо - в единственный каталог, в который разрешена запись, при условии что он находится выше DocumentRoot. При этом, очевидно, файловая система, на которой расположен этот каталог, должна быть смонтирована в noexec.

>как и куда будет делать ?

Касаемо заливаемого пользователями контента (картинки там, файлы всяко-разные...), то его вполне можно писать и ниже DocumentRoot, при условии контроля заливаемого содержимого по его типу. Каталог, в который делается upload, должен быть закрыт и для листинга и для исполнения из него скриптов.

>ЛОР теперь филиал phpclub :)

Скоро движок сменит - на пхпнюк :)

> Как организовать _кеширование_ HTML, сгенерированного именно этим компонентом?

Элементарно. Даже пример лень приводить, ибо банальщина.

> чем вам не нравиться сделать одну директорию с правом записи и туда писать (аки сделано в smarty)?

собственно, я этого не говорил. Просто я понял что stellar - поклонник php safe_mode, соответственно и задал ему вопрос о том как он будет разбираться с типичными для safe_mode-хостингов проблемами.
Я сам лично считаю что stellar не прав и что php-скрипт должен выполняться с правами юзера - владельца сайта и соответственно в компании, где я работаю, именно так и настроено.

> Заказчик должен иметь право на изменение дизайна своего сайта. А вот лазить в код проекта - нет, не должен.

Хм, а директивы шаблонизатора уже не считаются кодом проекта? И какая
разница - испортит клиент код php в шаблоне или разметку шаблонизатора,
если итог одинаковый - звонок в техподдержку?

> Ключевое слово: ОТКЛЮЧЕНО. В той смеси HTML и PHP, по недоразумению своему называемой "шаблоном" можно ВСЕ.

А в Smarty можно сделать даже больше, чем всё. Такое можно натворить,
что создатель не опознает свой код ;)

> Достаточный на 100% шаблонизатор состоит всего из двух функций подстановки-замещения:

Классический пример: в шаблоне нужно знать, чётная строка массива в
цикле или нечётная. Относится ли определение чётности строк к логике или
всё-таки это задача представления? Спорный вопрос, не правда ли?

А про ZPT никто ничего внятного не сказал, а ведь я даже пример привел :)

> Значит, div.header { color: red } - это нормально, а h1 { color: red } - это костыль?

С точки зрения семантики - типа нужная вещь, с точки зрения вёрстки -
костыль, избыточная сущность, только вред от неё. Ведь h1 - это тот же
div, но уже отягощённый некоторыми своими свойствами, определёнными в
дефолтном стилевом файле браузера. При этом, сколько браузеров, столько
и вариантов этого h1 теоретически может быть. Взгляните на пример
дефолтного стилевого файла: http://www.w3.org/TR/CSS21/sample.html
Для h1 определены display, margin, font-size, font-weight.

[quote]Классический пример: в шаблоне нужно знать, чётная строка массива в цикле или нечётная. Относится ли определение чётности строк к логике или всё-таки это задача представления? Спорный вопрос, не правда ли?[/quote] Четность/нечетность строки в массиве строк - это свойство данной строки. Такое же, как и все другие свойства, например, ее длина. Многие шаблонизаторы позволяют неявно указать это и другие свойства при формировании списка.

>Хм, а директивы шаблонизатора уже не считаются кодом проекта? И какая разница - испортит клиент код php в шаблоне или разметку шаблонизатора, если итог одинаковый - звонок в техподдержку?

Разница большая. Испортить бизнес-логику и испортить представление. Точно такая же разница как заляпать грязью стекла у автомашины и полностью разобрать двигатель. В любом случае можно обратиться в техподдержку, но исправление дефектов представления - ПРОЩЕ, потому что не затрагивается бизнес-логика.

> Ключевое слово: ОТКЛЮЧЕНО. В той смеси HTML и PHP, по недоразумению своему называемой "шаблоном" можно ВСЕ.

>А в Smarty можно сделать даже больше, чем всё. Такое можно натворить, что создатель не опознает свой код ;)

Ну-ну. Если из Смарти убрана вся лишняя функциональность, ничего "такого" сделать не получится.

> Четность/нечетность строки в массиве строк - это свойство данной строки.

Ответ как-то не в тему. Вопрос был - насколько сложен должен быть в реализации шаблонизатор, насколько много он должен уметь, и где та граница между логикой и представлением. Простой шаблонизатор не знает, что такое чётная/нечётная строка. Ну, и отсюда далее напрашивается мысль, что если язык шаблонов становится настолько фичастным, как Smarty, то может не стоит выдумывать велосипед в виде ещё одного языка разметки, а пользоваться тем же php? Ведь фактически Smarty превратился в язык на котором можно писать и логику! На нём, например, легко можно написать многостраничную форму с проверками вводимых значений, с перенаправлениями в зависимости от введённыз данных без единой строчки php...

> Разница большая. Испортить бизнес-логику и испортить представление.

А где бизнес логика? Речь шла только о двух типах реализации представлений - 1) на чистом php и 2) с помощью шаблонизатора.

>Вопрос был - насколько сложен должен быть в реализации шаблонизатор, насколько много он должен уметь, и где та граница между логикой и представлением.

Ответ: в зависимости от конкретных требований по визуализации. В некоторых проектах достаточно только подставить переменные а-ля {$foobar}, для других проектов нужны циклы и условия, кое-где не обойтись без XSL и встроенных функций.

>Простой шаблонизатор не знает, что такое чётная/нечётная строка.

А еще более простые шаблонизаторы не знают, что такое ветвления и циклы. И? Что есть "простой" шаблонизатор? Где его определение?

>Ну, и отсюда далее напрашивается мысль, что если язык шаблонов становится настолько фичастным, как Smarty, то может не стоит выдумывать велосипед в виде ещё одного языка разметки, а пользоваться тем же php?

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

>Ведь фактически Smarty превратился в язык на котором можно писать и логику! На нём, например,

Это - проблема Смарти. На свете есть не только Смарти, это во-первых, а во-вторых, даже от Смарти можно открутить все лишнее.

>А где бизнес логика? Речь шла только о двух типах реализации представлений - 1) на чистом php и 2) с помощью шаблонизатора.

Реализация на чистом PHP позволяет (считайте - провоцирует) вынесение бизнес-лигики в шаблон. Более того, подобный шаблон еще и небезопасен, ввиду того, что выполняется в контексте PHP.

Шаблонизатор же во-первых, имеет гораздо более редуцированную функциональность, во-вторых, в нем доступны только те данные, которые допустимы к визуализации и в-третьих, он более безопасен ввиду того что выполняется не в контексте PHP.

> Реализация на чистом PHP позволяет (считайте - провоцирует) вынесение бизнес-лигики в шаблон.

Так я и прошу дать определение границе, где кончается представление и начинается логика. Хотя бы на примере чётной/нечётной строки в массиве данных.

> Шаблонизатор же во-первых, имеет гораздо более редуцированную функциональность

Так в том его сила и в этом же его слабость ;) Кроме примера с чётностью могу предложить пример с необходимостью определения в представлении первой и последней строки в цикле. С точки зрения логики оно нафиг не нужно, это чистый дизайн. И таких примеров я могу приводить до бесконечности, всё более кусложняя задачу шаблонизатору ;)

> Не надо перегибать палку и бросаться в крайности (именно поэтому лично я против XSLT).

Это не перегиб, а лишь один из методов решения проблемы разделения логики и представления. Просто есть два основных подхода:

Первый. В блоке логики выгоняется сырой массив данных в блок представления, а уж что там блок представления сделает с этими данными - никого не волнует. На то оно и представление, и бесконечно число вариантов представления одних и тех же данных...

Второй. Представление максимально ограничено по функциональности и по-военному простое. На любой дизайнерских чих нужно подкручивать логику.

>Неправда. Подсветку можно сделать, например, вот так:

Вот ты и привёл уже _код_ :) Кстати, в Smarty всё примерно так и выглядит.

>Фанаты XSLT могут привести пример, как это сделать на XSL, это не намного сложнее.

Намного. Синтаксис XML - это ужас для ручной работы :)

>Для этог НЕ нужен _исполнимый_код_. Достаточно только выразительного движка шаблонизатора.

Ну уж естественно, под кодом подразумевается не бинарный машкод процессора :) Но код шаблонизатора от этого кодом быть не перестаёт.

>Так я и прошу дать определение границе, где кончается представление и начинается логика. Хотя бы на примере чётной/нечётной строки в массиве данных.

Пожалуйста. Представление - это визуализация без модификации объектной модели данных.

Обращение к readonly свойству элемента "чет"/"нечет" - это не модификация, а проверка свойства. Также, как получение длины строки

// В коде

String s;

<!-- В шаблоне -->

{$s.length}

>Кроме примера с чётностью могу предложить пример с необходимостью определения в представлении первой и последней строки в цикле.

Это - тоже readonly свойство. Шаблонизатор, по определению, не меняющий модель данныз, не может изменить это свойство, он только читает его.

>С точки зрения логики оно нафиг не нужно, это чистый дизайн.

>И таких примеров я могу приводить до бесконечности, всё более кусложняя задачу шаблонизатору ;)

Приводите-приводите.

=== quote ===
Давайте посмотрим.

<ul id="navigation">
<? foreach($menu_items as $i): ?>
   <? if($i['selected']): ?>
      <li class="selected"><?=$i['text']?></li>
   <? else: ?>
      <li><a href="<?=$i['url]?>"><?=$i['text']?></a></li&a
mp;g
t;
   <? endif; ?>
<? endforeach; ?>
</ul>

Один цикл и одно ветвление.
Ваш вариант?
=== quote ===

На Смарти будет так:
<ul id="navigation">
{foreach from=$menu_items item=i}
    {if $i.selected}
      <li class="selected">{$i.text}}</li>
    {else}
      <li><a href="{$i.url}">{$i.text}></a></li>
    {/if}
{/foreach}
</ul>

Плюсы: 

- меньше писанины (в более сложных случаях выигрышь может быть ещё
  больше).

- чётче визуально отделён HTML-код от кода разметки шаблона

- шаблон можеть быть в любом хранилище, хоть в файле, хоть в mysql-базе

- с шаблоном можно делать что угодно. Например, у меня все шаблоны в
  UTF-8, а при парсинге конвертируются в текущую локаль. В случае
  голого PHP требуется постоянно совать функции перекодирования

- скорость работы - такая же. Так как Smarty транслирует щаблоны в
  PHP-код

>> Ничто не мешает пользоваться шаблонизатором, написанным на С/C++.

>Для того, чтобы вместо <?=$foo?> писать {$foo}? Спасибо, рассмешили.

Smarty написан на PHP и может устанавливаться простым копированием :D

Все равно по читаемости до ZPT не дотягивает :) Вопрос по функционалу: как будет выглядеть в smarty код, который заполняет нужными данными некоторое заранее определенное пространство то в одном шаблоне, то в другом, в зависимости от некоего условия.

>Давайте посмотрим.

Давайте.

Мой вариант такой (вариант, который используется у меня в шаблонизаторе):

<ul id="navigation">
[loop menu_items]
  [if]<li class="selected">[text]</li>
  [else]<a href="[url]">[text]</a>
  [/if]
[end loop]

Плюсы все те же, вдобавок:

- работает быстрее ибо писано на С++ и не интерпретируется каждый 
раз, а используется как байткод.

- работает безопаснее ибо не интерпретируется PHP

- работает с Perl, PHP и С/С++, что дает возможность использовать тот 
язык, который более удобен и не быть привязанным только к PHP

Касаемо же Смарти, то у нас в организации он был переписан именно под
этот синтаксис чтобы можно было ставить проект туда, где нет 
возможности грузить модули через dl();