Обсуждение статьи о шаблонизаторах

[Фанат]

Обсуждение статьи о шаблонизаторах

http://wiki.envos.org/Glavnaja/Shablonizatory?v=gfp

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

есть толкьо одно замечание.
Раздел "Представление с преобразованием", 2 возражения:
1. в шаблонах "без логики" логика есть.
подробнее см. http://community.livejournal.com/ru_php/789059.html

2. "элементы форм проще формировать в самом скрипте-преобразователе" - не согласен категорически.
С чисто теоретической точки зрения толкаемой мысли, о том, что "и шаблон, и «преобразователь» находятся в слое представления" - верно. С точки зрения того, ради чего городился весь огород - чудовищно.
ради упрощения "шаблона" пихаем хтмл в преобразователь и в результате получаем... ДВА шаблона, один "простой" и другой "сложный" вместо одного "сложного". НОНСЕНС!

 

[_RVK_]

>1. в шаблонах "без логики" логика есть.

Ну об этом в статье написанно. Просто эта логика находится в "преобразователе". Удобно или нет, это кому как. Мне не удолбно, а кому-то в самый раз.

>2. "элементы форм проще формировать в самом скрипте-преобразователе" - не согласен категорически.

Например плагины смарти html_*. Смарти позвоялет этоту логику писать непосредственно в шаблонах, однако удобнее так, и реиспользование кода повышает. А в "представлении с преобразованием" формирование таких типовых конструкций вообще в сплошной геморой выливается. Так что гораздо удобнее написать функцию.

 

[Фанат]

Просто эта логика находится в "преобразователе".

нет.
ты, наверное, невнимательно читал.
Я утверждаю, что логика как раз в шаблоне, а не в преобразователе.
Давай, ты ,всё-таки, прочитаешь аргументацию по ссылке, а? Ну, просто, чтобы её здесь не повторять?

Мне не удобно, а кому-то в самый раз.

мне тоже неудобно. но речь не об этом. А о том, что говорить, будто это шаблоны без логики -самообман.
Логика _подразумевается_. Не имея в голове логического смысла блока, создатель шаблона просто не сможет его написать. Есть она, логика. Только не чёткая, а "ты не выпендривайся, а руками покажи!"
при чтении такого шаблона о смысле блока надо _догадываться_, исходя из фантазии человека , писавшего блоку название.

-~{}~ 04.10.06 16:49:

Например плагины смарти html_*.

можно поподробнее?
я не знаю Смарти на таком уровне

 

[_RVK_]

Ладно, согласен. Но это все равно что категорически утверждать что снег белый. Ну не белый он! Близко, но не белый. Абсолютно белое тело весь свет отражает.... То есть я с тобой согласен, но еще подумаю стоит ли эту мысль доводить в статье и в какой форме

-~{}~ 04.10.06 16:53:

можно поподробнее?

Отличный пример плагин html_select_date

Сам им очень часто пользуюсь.

 

[itprog]

а у меня envos.org не грузится :\

 

[_RVK_]

Странно...

 

[itprog]

7 * * 21 ms so-3-0-0.RT033-001.spb.retn.net [81.222.0.81]
8 19 ms 19 ms 19 ms GW-Eltel-3.retn.net [81.222.1.10]
9 370 ms 22 ms 23 ms gi-2.rt033-301.eltel.net [81.222.255.173]
10 20 ms 20 ms 19 ms 81.222.223.10
11 * * * Превышен интервал ожидания для запроса.
12 * * * Превышен интервал ожидания для запроса.

а c прокси все нормально...

 

[denver]

Фанат
Для объективности про XML+XSL не написали, хотя вероятно он и есть тот самый мифический (хотя уже реальный) шаблонизатор, в плане разграничегтя логик.

 

[akd]

denver, XSL в плане разделения логики, ничем не отличается от всяких смарти, фасттемплейтов и native code.

 

[_RVK_]

Для объективности про XML+XSL не написали

Статья не описание шаблонизаторов а описание концепций. XML+XSLT это "представление с преобразованием".

Но вот когда я допишу примеры, которых там нет, видимо пример с XML+XSLT придется тоже привести.

 

[denver]

_RVK_
Ах, да. Есть там про XSLT, но только почему-то не в разделе о "Представление по шаблону" в котором

>В шаблоны Smarty передаются данные, и уже сам шаблон определяет как эти данные показать

А, как вы и говорите, в разделе "представление с преобразованием" где он сравнивается с "пассивным" FastTemplate. Почему-то я считал всегда что к XML+XSL наиболее близок smarty чем FastTemplate. Вы вообще пробовали на практике?

 

[_RVK_]

denver
Признаюсь что опыта использования XSLT мало. Но в данном случае я руководствовался опытом Мартина Фаулера, о чем указал в статье. Так же, опираясь на свои скромные знания, я все таки считаю что это типичное "представление с преобразованием". XML это шаблон, а XSLT это "преобразователь". В случае с фастемплейте, роль XML выполняет шаблон, а роль XSLT выполняет PHP.

 

[denver]

Так ведь если шаблон это оформление данных, он же не содержит данные, а только инструкции как выводить данные, которые ему доставляют. XML содержит ТОЛЬКО данные, не содержит ничего что касается оформления -- лишь структурно, иерархически распределенные данные. XML это лишь способ (пре)доставить данные (!) XSL-шаблону (По аналогии в смарти доставляет assign(), в fasttemplate set_var() и т.п).
Т.е. XML можно считать обыкновенным многомерным массивом с данными, но никак не шаблоном. Даже не требуется никаких шаблоннов XML файлов с <?=$var?> вставками (как и не требуется верстальщик для "верстки" этих XML) достаточно некоей функции которая преобразовывает PHP массив в XML код и всё.

XSL же (напротив) это типичный шаблон+преобразователь два в одном т.к. он содержит лишь инструкции по отображению и оформлению (данных из XML-ного "массива").

ЗЫ. Я не против статьи, хорошая статья, но вот тема XML+XSL не только не раскрыта но и действительно неправильно позиционирована

 

[_RVK_]

denver
Открываем стр. 84 книги Фаулера "Архитектура корпоративных програмных приложений" и читаем: "Премером представления с преобразованием может служить XSLT.... Входной контроллер выбирает подходящую таблицу стилей XSLT и применяет ей к XML коду, описываещему модель...."

От себя замечу что ты опять привязываешься к конкретным реализациям, а в статье разговор идет о теории. На самом деле Смарти, это вовсе не "представление по шаблону" а пример двухэтапного преобразования, о чем сказанно в сноске. Чистое "представление по шаблону" это как раз PHP. Может это моя ошибка, что я сознательно упростил теорию, пытаясь донести суть. Просто я пытаюсь абстрогироваться от конкретных реализаций, и говорить лишь в терминах технологий.

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

 

[Фанат]

_RVK_
denver прав на 100%
Дело не в том, как ты излагаешь мысли ,а в том, что ты излагаешь мысли, противоречащие истине.
я не буду повторять то, что он написал - там очень доходчиво.
просто исправь в своей статье, чтобы не портить её имидж такими досадными, но вызывающими очень нехорошее впечатление об уровне статьи в целом, ошибками.

 

[zarus]

Языковые ошибки. Или "Опять двойка".

1. (многие до сих пор в этом уверенны)
Исправление: уверены
2. Борщ только на первый взгляд кажется хаусом
Исправление: хаосом . Хаус = house = дом. Хаос = chaos.
И вообще, борщ лично мне не кажется хаосом, а очень аппетитно выглядит
3. На самом деле хорошо приготовленный борщ он вкусный.
Исправление: На самом деле, хорошо приготовленный борщ - он вкусный.

4. Подумал, и решил, что автору статьи просто нужно воспользоваться услугами проверки MS Word.

Извиняюсь за "наезд", но читать грамотную статью на безграмотном языке - затруднительно. Вы ведь в скриптах не пропускаете точки с запятыми и кавычки?

 

[Rammstein]

Ничего эллегантней XSLT не видел.

 

[Yaponchick]

В этой статья я не
Кто-то обкурился, когда писал статью =)

 

[_RVK_]

Спасибо за поправки.

_RVK_
denver прав на 100%
Дело не в том, как ты излагаешь мысли ,а в том, что ты излагаешь мысли, противоречащие истине.

Я могу допустить что я не прав. Но перечить Фаулеру это крамола уже какая-то

Тем более что в статья ясно дается ссылка на Фаулера: "Мартин Фаулер приводит в качестве примера XSLT преобразование XML шаблона. Я же хочу привести пример более приближенный к реальности: Fast Template..."

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

 

[Alexandre]

лично мне удобно часть простой логики перенести в шаблон, это дает больше свободы, в том числе и дизайнеру, ему проще копаться в одном файле, нежеле в трех-пяти маленьких шаблончиках, которые принадлежат одному скрипту. Объяснить дизайнеру (верстальщику) принадлежность тегов {for} {if} не так уж и сложно.

я не знаю, правильно или нет,
но я стараюсь придерживаться правилу - один скрипт (класс), один шаблон

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

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