по-русски через дефис пишется.
Грамотеи.

так уже об этом писали пару недель назад

хотя сайт действительно интересен

Я-ж не лигвист. И на звание грамотея не притендую. :) Всего-лишь обычный программер. :)

Дык плохо что и модератор, пропускающий сообщения, не претендует...ж-)

Ну, я думаю, что в данном случае приоритет не в грамотности текста, а в интересности новости. :) Если в тексте 1-2 ошибки, думаю это не страшно.

надо же, какие мы грамотные.

учителем русского языка в школе работаешь?

Скажите, что в нём интересного? ИМХО вредный тулкит. Ну сами посудите -
они предлагают пихать в html-шаблон такую конструкцию:

[% webpages = [
{ url => 'http://foo.org', title => 'The Foo Organisation' }
{ url => 'http://bar.org', title => 'The Bar Organisation' }
]
%]

Налицо смесь данных и презентации. И там кругом так. Короче, просто
криво реализована функциональность php. Причём, голого php. Сейчас
даже на php никто не пишет без шаблонов, чётко отделяющих данные, код
и оформление. Резолюция: ф топку.

Комментс?

Совершенно согласен. Вместо разделения логики и оформления просто добавляется еще один уровень скриптописания. Уж если так подходить к "шаблонам", то лучше PHP или embeded perl.

Они не заставляют писать такую конструкцию. 
Хочешь - пиши просто

<h3>[% title %]</h3>
<a hre=[% url %]></a>

и задавай эти переменные в вызывающем Perl скрипте
и будет чистый шаблон. 
Для желающих есть возможность часть логики написать внутри шаблона. 
Для особенных энтузиастов можно записать весь код внутри шаблона 
и вообще не писать вызывающие скрипты. 
Вообщем все зависит от головы того кто пишет.
А выносить такие резолюции означает показывать собственную ограниченность.

По сравнению с HTML::Mason просто смещная игрушка...

Еще TT2 хорош тем что все шаблоны преобразуются движком в чистый Perl код (с возможностью включения кэширования преобразованного кода) и поэтому все прекрасно интегрируется с mod_perl.

> Скажите, что в нём интересного? ИМХО вредный тулкит. Ну сами посудите - они предлагают пихать в html-шаблон такую конструкцию:

> [% webpages = [
> { url => 'http://foo.org', title => 'The Foo Organisation' }
> { url => 'http://bar.org', title => 'The Bar Organisation' }
> ]
> %]

> Налицо смесь данных и презентации.

Эээ... Не вижу ничего плохого в описании _констант_ в шаблоне. Взять тот же XML/XSLT, там же не зазорно сущности использовать...

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

Ну скажем Mason надо сравнивать не с Template Toolkit a c Maypole например или с другими framework'ами. А TT2 это очень гибкая template система. И все.

> Еще TT2 хорош тем что все шаблоны преобразуются движком в чистый Perl код

Сто лет в обед, как Smarty использует то же самое.

> Хочешь - пиши просто
> <h3>[% title %]</h3>

Ну это уж совсем просто ;) Для таких конструкций я не стал бы даже 
шевелиться, чтоб искать какой-то там новый тулкит.

Смотрим примеры далее:

  [% FOREACH project = worklist(me.id) %]
       <li> <a href="[% project.url %]">[% project.name %]</a>
  [% END %]

Что это? Это микс логики с шаблоном. Всё бы было более менее пристойно,
если бы не появился (my.id). Курите доки по mvc2.

Ну и последний вопрос на засыпку: чего не хватало в существующий для
перла шаблонов, таких как, например, HTML::Template? Существуют много 
лет, отлично обкатаны и оттестированы, и фич по более будет. Чего не 
хватало?

> Эээ... Не вижу ничего плохого в описании _констант_ в шаблоне.

А такие ли уж они константы? И если они вправду константы, то чего
мудрить с nested block? Проще ведь написать нормальный html-код и
не мудрить.

Не а, все здесь в порядке. Никакого микса. :) Аналогичная конструкция в XSLT:

<xsl:foreach select="a"> </xsl:foreach>

А как иначе Вы предлагаете списки переменной длины отображать? :) HTML::Template тоже содержит аналогичную конструкцию <TMPL_LOOP NAME="..."> :)

Может, еще и числа форматировать код должен, и списки для вывода сортировать (кстати, HTML::Template этого делать не умеет, за что я его не люблю)? :)

Код должен отдавать "сырые" данные, а шаблон их форматировать и расставлять по местам. По-моему, так :)

> А такие ли уж они константы? И если они вправду константы, то чего мудрить с nested block? Проще ведь написать нормальный html-код и не мудрить.

А если они неоднократно там встречаются? В случае изменений же придется перелопачивать тогда весь HTML, а тут просто в одной точке изменить, и все. Да и нагляднее оно может быть, в конце концов :)

> В случае изменений же придется перелопачивать тогда весь HTML

Отсюда напрашивается естественный вывод: они - не константы ;)

> А как иначе Вы предлагаете списки переменной длины отображать?

В шаблоне маркируется nested block c переменными. На вход блока подаётся
готовый массив.

> HTML::Template тоже содержит аналогичную конструкцию

Там нет произвольной логики выдачи данных. Простой перебор. А в том
примере из tt2 в шаблоне определялся параметр, типа ключа к подаваемому
массиву.

> Может, еще и числа форматировать код должен, и списки для вывода сортировать

Числа... иногда может возникнуть такая потребность. Пример? Вывод каких
нибудь вычислений и результатов, тип которых изначально определить не
представляется возможным. Случай редкий, но исключать его нельзя.

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

> Отсюда напрашивается естественный вывод: они - не константы ;)

Не напрашивается вовсе. Есть вещи, которые не меняются очень подолгу, а, если меняются, то только руками, и программист имеет право облегчить себе труд, вынеся это в константы туда, где исправить это можно будет попроще. Особенно для большого проекта.

> В шаблоне маркируется nested block c переменными. На вход блока подаётся готовый массив.

> Там нет произвольной логики выдачи данных. Простой перебор. А в том примере из tt2 в шаблоне определялся параметр, типа ключа к подаваемому массиву.

Почему бы и нет? Почему нельзя в шаблоне определять, какие данные показывать, а какие не нужно? Затаскивать это в логику - ограничивать общность приложения. Осмысленно, конечно, бывает, но, как правило, на очень больших массивах или по соображениям безопасности.

> Числа... иногда может возникнуть такая потребность. Пример? Вывод каких нибудь вычислений и результатов, тип которых изначально определить не представляется возможным. Случай редкий, но исключать его нельзя.

Разрешимая проблема. Тип результата можно передавать с данными. Форматировать числа в коде, ИМХО, в любом случае не стоит.

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

Можно. Но это не отменяет принципа, что сортировка должна быть в шаблоне. Как сортировать в правильном порядке - песня отдельная, но и это разрешимо :)

Приложение вообще не должно знать, как должны отображаться данные, оно должно их просто передавать. Форматирование, сортировки, выборки должен производить шаблон. Исключения очень редки. Как правило, это безопасность и производительность.

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

> Не напрашивается вовсе. Есть вещи, которые не меняются очень подолгу, а, если меняются, то только руками, и программист имеет право

Да имеет право написать в шаблоне:

<div class="webpages">[% webpages &]</div>

И передать в шаблон переменную переменнную webpages, которая вполне может быть сформирована в отдельном шаблоне. И да, он имеет право
прописывать эту конструкцию сколько угодно раз на странице.
Разница между исходным примером ясна? Я про вот это:

[% webpages = [
{ url => 'http://foo.org', title => 'The Foo Organisation' }
{ url => 'http://bar.org', title => 'The Bar Organisation' }
]
%]

> Приложение вообще не должно знать, как должны отображаться данные, оно должно их просто передавать.

Гм. У нас разное понятие о "передавать"; Я тоже передаю "данные", но
уже отсортированные. Нет, несогласен абсолютно. Сортировка - это
_далеко_ не всегда презентация данных, и к разметке она так же не имеет
никакого отнощшения. Сортировка сама по себе может быть данным! От неё
может зависить, например, судьба человека: то ли он окажется в начале
списка, то ли в конце ;)

Это ещё ерунда. Тут относительно всё понятно. Я видел большие дискуссии
относительно принадлежности к данным/презентации выделения в фин.отчёте
отрицательного баланса красным цветом. И аргументы были железными
с обеих сторон.

> Почему нельзя в шаблоне определять, какие данные показывать, а какие не нужно?

Не вполне правильный вопрос. Лучше спросить так: Почему нельзя в шаблоне
определять, какой ключ массива задействовать для заполнения таблицы?

> Сортировка сама по себе может быть данным!

Примеры, примеры :) Уж очень похоже на сферического коня в вакууме :)

Даже если такое и есть, то случай редкий. И ничуть не отменяет того, что в большинстве случаев сортировку можно и нужно применять на уровне шаблона.

> Это ещё ерунда. Тут относительно всё понятно. Я видел большие дискуссии относительно принадлежности к данным/презентации выделения в фин.отчёте отрицательного баланса красным цветом. И аргументы были железными с обеих сторон.

<xsl:choose>
<xsl:when test="number(x) &lt; 0">
<font color="red"><xsl:value-of select="x"/></font>
</xsl:when>
<xsl:otherwize>
<xsl:value-of select="x"/>
</xsl:otherwize>
</xsl:choose>

Ы? :) Передаваемые шаблону данные должны быть нормализованы :) Денормализация может быть оправдана, как правило, требованиями производительности или ограничениями языка описания шаблона.

> Да имеет право написать в шаблоне:

<div class="webpages">[% webpages &]</div>

> И передать в шаблон переменную переменнную webpages, которая вполне может быть сформирована в отдельном шаблоне. И да, он имеет право прописывать эту конструкцию сколько угодно раз на странице. Разница между исходным примером ясна? Я про вот это:

> [% webpages = [
> { url => 'http://foo.org', title => 'The Foo Organisation' }
> { url => 'http://bar.org', title => 'The Bar Organisation' }
> ]
> %]

Некорректное сравнение. Абсолютно.

Ближайшие аналоги:
<!ENTITY url "http://foo.org">
<xsl:variable name="url">http://foo.org</xsl:variable>

Внутри шаблона можно объявлять и использовать константы. Можно и зачастую нужно. Особенно в больших проектах, где поддержка может стоить очень дорого.

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

Я отвечу, почему нужно. Потому что в идеале софтина, передающая данные в шаблон, вообще ничего не должна "знать" о том, как эти данные будут представляться. Это должен "знать" только шаблон. Все остальное от Васи Пупкина :)

> Внутри шаблона можно объявлять и использовать константы.

Очень широкий термин получился - "константа". Трудно даже что-то
возразить ;) С моего угла зрения та конструкция смотрится явно как блок
переменных данных, насильно воткнутый в шаблон.

> в идеале софтина, передающая данные в шаблон, вообще ничего не должна "знать" о том, как эти данные будут представляться.

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

> Некорректное сравнение. Абсолютно.

Я написал: "переменнную webpages, которая вполне может быть сформирована
в отдельном шаблоне".

> большинстве случаев сортировку можно и нужно применять на уровне шаблона.

Я не отрицаю, но и не считаю это абсолютной истиной. Сортировка может
относиться к элементам логики и управляться из модели. Смена сортировки
при показе может нарушить логику, например произойдёт смена алгоритма
LIFO на FIFO, если над этими данными пользователь производит дальнейшие
операции...

> <xsl:when test="number(x) &lt; 0">

Значит, здесь такая проблема: всё зависит от того, каково точное
условие. Сравни два примера:
1) показать красным отрицательный баланс.
2) показать красным превышение ограничения по кредиту (баланс так же отрицателен)

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

Re[10]: Template Toolkit по русски

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

"К подсудимому вопросов больше не имею" (с) :D

Шаблон устанавливает представление данных. Все остальное (как расширение так и ограничение) от нечистого. :)

Пример с FIFO/LIFO некорректен и решается штатными средствами шаблонов (даже в убогом HTML::Template это можно).

> Очень широкий термин получился - "константа". Трудно даже что-то возразить ;) С моего угла зрения та конструкция смотрится явно как блок переменных данных, насильно воткнутый в шаблон.

Синтаксически да, смотрится убого, как и <xsl:variable> для объявления констант. Но в данном случае главное не синтаксис, а смысл действия.

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

Знать не должен, но шаблон должен знать, какие данные окрашивать красным. Путей для этого масса. Сравнивать же можно не только с нулем, правда?

> Сравнивать же можно не только с нулем, правда?

Сорри, это уже пошла логика и модель данных. Шаблон - это тупая форма,
в которую умные данные втискиваются. Неплохо, конечно, если он сможет
отличить нуль от ненулевого значения, но специально требовать от него
чего-то большего мы не вправе. Я понимаю, что несколько отхожу от шаткой
теории, но на то она и теория, чтобы корректироваться практикой.
В стремлении сделать view умным, элементарно можно подойти к той черте,
где view начнёт брать на себя и функции модели.

> шаблон должен знать, какие данные окрашивать красным

Ну, то есть шаблон должен брать на себя функции анализа поступающих
данных в рамках бизнес-модели, правильно? ;)

Анализ анализу люпус ест.

Но шаблон должен уметь справляться с простейшими случаями.

> Приложение вообще не должно знать, как должны отображаться данные, оно должно их просто передавать. Форматирование, сортировки, выборки должен производить шаблон. Исключения очень редки. Как правило, это безопасность и производительность.

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

> Но шаблон должен уметь справляться с простейшими случаями.

Гы, а я разве что-то другое утверждал? Наоборот, я к тому и клоню, что
_только_ простые. Проблема в определении границы
простые->несложные->не_совсем_простые->относительно_несложные и т.д. ;)

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

Вычислительные, как правило. Плюс обработка поступающих данных.

От слишком простых языков шаблонов пользы мало. Шаблоны предназначены для того, чтобы верстальщик в случае изменения вида документа мог справиться без программиста в большинстве случаев. А сортировка данных - это вид документа. Группировка - тоже вид. Форматирование чисел - туда же. Определение цвета отображения данных тоже относится к форматированию.

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

А что, ты думаешь, грамотность только учителям нужна? Вроде же сайт не про N'Sync. Все тут такие умные и образованные. А простейших правил не знают. Может ты еще и ножом и вилкой есть не умеешь?

Утверждение

"От слишком простых языков шаблонов пользы мало."

противоречит

"Шаблоны предназначены для того, чтобы верстальщик в случае изменения
вида документа мог справиться без программиста"

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

> Вычислительные, как правило. Плюс обработка поступающих данных.

А что есть вычислительные задачи? Подсчет сумм и средних значений --- это вычисления или нет?

> От слишком простых языков шаблонов пользы мало. Шаблоны предназначены для того, чтобы верстальщик в случае изменения вида документа мог справиться без программиста в большинстве случаев.

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

> А сортировка данных - это вид документа. Группировка - тоже вид.

Crosstab отчеты, подсчет агрегатных значений, определение выхода за границы? Все в шаблоне?

> Форматирование чисел - туда же.

Определение до какого знака округлить, кол-во знаков после запятой иногда требует некоторых расчетов. Где будем считать?

> Определение цвета отображения данных тоже относится к форматированию.

Только цвет определяется не на основании значений данных, а на основании свойств, которые были определены (вычислены) моделью.

> Утверждение

> "От слишком простых языков шаблонов пользы мало."

> противоречит

> "Шаблоны предназначены для того, чтобы верстальщик в случае изменения вида документа мог справиться без программиста"

Не понял. Где противоречие?

> А что есть вычислительные задачи? Подсчет сумм и средних значений --- это вычисления или нет?

Вот это в самом деле неоднозначно. Тут даже не очень понятно, на каком слое такое действие можно производить. Мне кажется, что на любом :) Поэтому такую вещь я бы, наверное, без нужды в шаблон не стал бы впихивать из соображений производительности, хотя иногда это может быть оправданным.

> определение выхода за границы?

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

> Только цвет определяется не на основании значений данных, а на основании свойств, которые были определены (вычислены) моделью.

Значит, надо передавать вычисленные свойства. Но уж точно, указывать цвет в передаваемых данных нельзя. В крайнем случае вешать флажок, что данные должны быть как-то выделены. Нужно отделять данные от их представления, иначе смысл шаблона теряется.

> Вот это в самом деле неоднозначно. Тут даже не очень понятно, на каком слое такое действие можно производить. Мне кажется, что на любом :) Поэтому такую вещь я бы, наверное, без нужды в шаблон не стал бы впихивать из соображений производительности, хотя иногда это может быть оправданным.

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