Использование Шаблонов технологии, принцип и все ЗА и ПРОТИВ

[denver]

RaZEr
Пока что ни одной неразрешимой проблемы я не услышал. Это тоже факт

[RaZEr]

Пока что ни одной неразрешимой проблемы

Неразрешимых проблем нет. Есть стоимость и сроки решения проблем, и на сегодня они не всегда в пользу XML.

[denver]

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

[RaZEr]

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

В этом всё дело, что проще написать (ещё проще взять готовый) новый темплейтер, чем решать проблемы связанные с использованием XML-парсеров.

[denver]

RaZEr
Это уже другой вопрос. Собственно это я и хотел услышать.

[RaZEr]

Ну слава богу. Не подрались - уже хорошо

А по существу. Есть идеи как грамотно превратить невалидный XML в максимально валидный?

[denver]

RaZEr
Чтоб ты не подумал ничего хорошего я имел ввиду что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано

Максимально валидного XML не бывает (бывает валидный или нет). XML по сути не предназначен для правки человеком (хотя и не исключает этого). XML должен создавать программист (через скрипт) а не пользователь. Если прораммист граммотный то XML будет валиден всегда, даже если содержит текст пользователя. Если текст пользователя содержит HTML то его можно автоматом приводить к XHTML либо пропускать через htmlspecialchars(). Я еще не видел написанной кем-то реализации HTML->XHTML, наверное от htmlspecialchars() никто пока не страдал.

[RaZEr]

что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано

А как же вы, любезный, поступаете, когда не повезло с хостингом? "Качество не моей мануфактуры"?...

Максимально валидного XML не бывает

maximum = as much as possible = как можно более.

XML по сути не предназначен для правки человеком

Цитата с W3C будет?

наверное от htmlspecialchars() никто пока не страдал

Ты уже дал ответ на этот вопрос:

это соответсвует натуре человека -- чем разобраться...

[Sheryld]

как это я не заметил такую интересную дискуссию?

про валидный xml:

есть xml-схема, есть DTD, есть прочее, т.е. проблем с проверкой нету, есть проблема с составлением правил(что обрезать, а что нет).

про xslt:

предлагается следующее упражнение(типичная задача для вывода каталога):

1. есть некоторый xml-файл с данными(там только данные, как и предложил denver). что-то типа:

<catalog>
<item>
<id>1</id>
<title>АААААААА</title>
</item>
<item>
<id>2</id>
<title>БББББББББ</title>
</item>
<item>
<id>3</id>
<title>ВВВВВВВВв</title>
</item>
<item>
<id>4</id>
<title>ГГГГГГГ</title>
</item>
</catalog>
....

2. есть некоторый шаблон(xslt).

3. есть код на php, который выдает html(ну то есть типа: $xsltInstObj->out("my.xml","my.xsl")

внимание задача:

вывести все данные в n-столбцов, отсортированные свверху вниз, т.е. типа:

а г ж й
б д з
в е и

за n возьмем - 4(столбца)

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

если еще усложнить задачку, то вывод должен быть таким:

<table>
<tr>
<td>
1 элемент 1 столбца
</td>
<td>
1 элемент 2 столбца
</td>
<td>
1 элемент 3 столбца
</td>
<td>
1 элемент 4 столбца
</td>
</tr>
</table>

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

[denver]

Sheryld
Ну формулой будет ceil(count($items)/$n)) тут долго думать не надо. Особенность реализации зависит от конкретного языка будь то Smarty или XSLT, скорость реализации зависит от знаний/опыта верстальщика в этом языке.

Да, XSLT это в язык прораммирования (только вывода). Однако смешно смотреть на сборище снобов пэхапэшников которые так наивно уверены что верстальщик не может (не в состянии, не хватит мозгов, куда там) выучить язык программирования, что это только пэхапэшнику дано, но пэхапэшнику скучно его учить. Почему бы не рассматривать это и так: "нам нужен программер PHP(соотв. +MySQL,+Unix, etc) и программер XSLT(соотв. +HTML, +CSS etc)"? "Программер" XSLT будет ненамного дороже верстальщика HTML, однако в результате это будет настоящее отделение контента от оформления.

RaZEr
В спецификации PHP тоже не написано что код не предназначен для правки пользователем, тем не менее, ты обычно не советуешь заказчику менять даже константы в коде.
Аналогично хочется спросить -- "максимально валидный XML" -- цитата с W3C будет?

From RaZEr: Денвер! Личку - в ПС. Демогогию эту устраивай в другом месте!

[Sheryld]

дьявол кроется в деталях.

покажи реализацию на xslt.

[denver]

Sheryld
Ну скажем вот решение для n=4:

<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<head>
  <title>Four columns layout</title>
</head>
<body>

  <xsl:variable name="maxperrow" select="ceiling(count(//item) div 4)"/>
  <xsl:variable name="col" select="//item[position() &lt;= $maxperrow]"/>

  <table border="1" cellpadding="5">
  <xsl:for-each select="$col">
    <xsl:variable name="current" select="position()"/>
    <tr>
      <td><xsl:value-of select="//item[$current+$maxperrow*0]/title"/></td>
      <td><xsl:value-of select="//item[$current+$maxperrow*1]/title"/></td>
      <td><xsl:value-of select="//item[$current+$maxperrow*2]/title"/></td>
      <td><xsl:value-of select="//item[$current+$maxperrow*3]/title"/></td>	
    </tr>
  </xsl:for-each>
  </table>

</body>
</html>

Может шокировать конечно количество XSL кода (можно было бы обойтись без переменных, но так нагляднее и удобнее), на практике HTML намного больше конечно. В любом случае не вижу особенных слжностей, на Smarty решение было бы похожим.

[Sheryld]

не знаю как вам, мне определенно понравилось.

[Hubbitus]

denver:
Да, XSLT это в язык прораммирования (только вывода). Однако смешно смотреть на сборище снобов пэхапэшников которые так наивно уверены что верстальщик не может (не в состянии, не хватит мозгов, куда там) выучить язык программирования, что это только пэхапэшнику дано, но пэхапэшнику скучно его учить.

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

denver:
Чтоб ты не подумал ничего хорошего я имел ввиду что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано

Интересно, а разбираться в уже написанном (тотже Смарти) или темболее написать что-то свое это лень разбираться с XML и XSL??? Странная логика однако, вот ведь лентяи блин, эти создатели Smarty!...

[RaZEr]

Сообщение от denver

Аналогично хочется спросить -- "максимально валидный XML" -- цитата с W3C будет?

Причем же здесь W3C. Это не утверждение, а формулировка. Вполне понятная. Необходимо (было) добиться максимально возможного приближения HTML к XHTML. Но да ладно, - вопрос снят. От греха подальше, как говориться

Ну а отсюда снова начальный вопрос, почему верстальщику тогда не выучить несколько конструкций PHP, раз все согласились что решение будет равносильно, а именно нужно XSLT

Если у нас есть: А - набор информации выданной скриптом, Б - шаблон определяющий порядок и количество информации, В - стиль оформления задающий внешний вид. То мы можем создать XHTML при помощи PHP, а затем его оформить XSLT стилем. Тогда все останутся довольны

[denver]

Hubbitus
PHP в качестве языка логики оформления Ну это ты вернешься к тому с чего начал: <?=$color?> и т.п., тоже неплохо собственно
А если серьезно, то просто возникнет вопрос безопасности, PHP в этом плане шибко мощный.

RaZEr

мы можем создать XHTML при помощи PHP, а затем его оформить XSLT стилем

Эээ.. тоже конечно можно. Однако это получится что из одного шаблона мы делаем другой шаблон, а потом уже HTML.

ЗЫ.

[Sheryld]

тут есть одно фундаментальное преймущество.

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

я вобщем об этом писал, немного выше:

А если это программирование вывода будет на PHP и отдельно от программирования бизнес-логики, то помоему это вполне подходит под твое 2 разделение...

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

[RaZEr]

Сообщение от Sheryld

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

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

[Sheryld]

я не о php в целом, а о smarty в частности.

если все делать по-человечески, то вся логика отображения и верстка перейдут из php — куда угодно, практически без правок. меняем только бизнес логику и парсер.

пример: переезд сайта с php на asp.net.

[RaZEr]

Пример плохой (не часто такие переезды происходят), но я с тобой согласен - из связки FastTemplate, Smatry, XSLT последний будет предпочтительнее.