LokiDi L0ck

У нас web-frontend клиентской базы реализован на extjs. Система приличная (функциональности много), тормозов нет. Никто не жалуется, даже наоборот)

Chester, и?

В данном случае - нет

Предпочитаю второй вариант). Сам шаблонизатор не сложный, кто работал со smarty без проблем осилят все основные примочки. Кто решит пользоваться, будьте внимательней на освоении документации. Например конструкция {foreach} имеет параметры: Параметр name используется для именования итератора (и доступа к его свойствам). Доступ к самому итератору осуществляется через $.foreach.default (где default заменяется на name (если указан)) следующим образом: {foreach $items i name="myiterator"} $.foreach.myiterator.first {* Определяет первый ли элемент сейчас в блоке. Так же есть свойства: last, total, iteration, index и пр. (Смотрите в коде плагина) *} {/foreach}

Что вы все к индусам пристали (пусть даже образно выражаясь). Посмотрите на свой код (или своего сотрудника) - попытайтесь сдержать слёзы

Dwoo - совместима с шаблонами smarty, за исключением некоторых возможностей. Во всю использует ООП возможности php5 (реализовано даже наследование шаблонов в самих шаблонах через {extend "template.tpl"}). Имеется адаптер вида для Zend Framework. По заверению разработчика работает быстрее чем smarty. Все необходимые ответы имеются в документации

Покупал её в том году. Но после первых 50 страниц, избрачно полистал и понял, что ничего нового она не расскажет Но для людей "с нуля" сойдёт)

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

Yarik Voronov, всё прекрасно понимаю и прежде чем писать свой первый пост не раз уже обдумывал различные варианты. И как бы там нибыло, работать с формирующим xml документ скриптом так или иначе работать всё равно придёться. ZoNT, согласен. Потому и пояснил в первых постах: Всем остальным движет только интерес к эксперименту.

В курсе. Как и в том, что это не имеет к теме никакого отношения

ZoNT, вы меня не поняли Моя основная мысль: 1) Програмные шаблонизаторы (ПШ) позволяют вытаскивать произвольную информацию и обрабатывать её на месте (см. пример с {cms:category}). 2) XML+XSLT: зависит от логики формирующего XML СКРИПТА. Представьте, что на monitors.html всегда выводилось по 20 мониторов и больше ничего, т.е. СКРИПТ брал из базы 20 записей, формировал их в xml и отдавал на съедение xsl. Через некоторое время мы решили, что на monitors.html необходимо справа разместить список 3ёх самых раскупаемых мониторов. Это значит, что мы должны: a) Изменить СКРИПТ (Он помимо 20 записей, теперь достаёт ещё 3, и формирует XML с новыми тремя элементами.) Изменить .XSL файл (написать соответствующий <xls:template> для обработки новых 3 элементов) Теперь вернёмся к 1-ой мысли. Если бы мы пользовались ПШ, то нам было бы достаточно изменить сам шаблон - и всё. Что-нибудь вроде: До изменения: <div> Мониторы: <ol> {cms:section id="monitors"} <li>{title} - {model}</li> {/cms:section} </ol> </div> После добавления трёх популярных: <div style="width:50%; float: left;"> Мониторы: <ol> {cms:section id="monitors"} <li>{title} - {model}</li> {/cms:section} </ol> </div> <div style="width:50%;"> Популярные: <ol> {cms:section id="monitors" count="3" order="sale_number"} <li>{title} - {model}</li> {/cms:section} </ol> </div> Видите разницу? В случае xml+xslt помимо работы c .xsl, придёться работать и со скриптом.

Второй вариант не очень гибок в отношении управления информации самим шаблоном. (Всё далее теория) Предположим пользователь зашёл на страницу: /monitors/lcd/dell-3008.html Cms (после внутренней маршрутизации) определяет, что страница dell-3008.html ассоциирована со стилем monitor-detail.xsl layout.xsl (схема сайта) подключает monitor-detail.xsl Формируется xml с информацией по двум категориям (Мониторы (/monitors), Жидкокристаллические (/lcd)), о сайте (кодировка, описание и т.д.), каком-то конкретном меню, блоках (с id=5, 8) (которые должны выводиться только на данной страничке) и т.д. На стороне сервера xslt трансформирует xml - получаем результирующий документ. Теперь, представим, что понадобилось выводить другие блоки (с id=1, 9). Для этого придётся править логику в скрипте формирующем xml (в пункте 3) (а в случае с типичным php-шаблонизатором - в шаблоне можно было бы просто поменять id). Собственно, мне не очень импонирует невозможность извлечения произвольных данных ИЗ шаблона, т.к. с практической точки зрения (о xml, xslt) - пользователь помимо работы с шаблоном должен будет также работать и с скриптом, формирующем xml (а это лишние затраты на рабочие руки)

Собственно ситуация. Пишу cms в свободное время. Логику вида выполняют шаблонизаторы, которые можно свободно менять. Логика вывода того или иного информационного блока лежит на плечах шаблона. Например где-нибудь снизу справа должен выводиться список определённых категорий: <div> <p>Категории:</p> <ol> {cms:category id="5,6,7"} <li> <a href="{url}">{name}</a> {description} <hr> </li> {/cms:category} </ol> </div> Блок {cms:category} будет обработан шаблонизатором, где из базы будут вытянута необходимая информация по трём категориям и вставлена в шаблон блока три раза, для каждой категории соответственно. Так же есть специализированные блоки для вывода меню, страниц, блоков информации, различных деревьев и везде эти блоки вытягивают только необходимую информацию, без каких-либо излишеств. Теперь я подумал, что неплохо было бы иметь возможность клепать шаблоны с помощью xml+xslt (и в таком ракурсе никогда с ними не работал). Так как в моём представлении шаблон имеет право доставать и формировать информацию для вывода, тут появляется вопрос: чтобы вывести произвольные блоки, деревья и пр. информацию из базы в результирующий документ, нужно ли ВСЕ эти данные формировать в xml? Например, если мы захотим вывести на какой нибудь страничке список определённых категорий, то это значит - что мы должны иметь xml со всеми категориями сайта. Чтобы xslt мог вытащить их например так: <div> <p>Категории:</p> <ol> <xsl:apply-templates select="//category[@id=5 or @id=6 or @id=7]"/> </ol> </div> ... <xsl:template match="category"> <li> <a href="{url}"><xsl:value-of select="name"/></a> <xsl:value-of select="description"/> <hr/> </li> </xsl:template> А если я хочу вытащить два информационных блока (а их в базе 50 000)? xslt'у необходим xml с этим списком, т.к. иначе он информацию получить не может. В итоге скорость не ахти. Можно конечно воспользоваться XSLTProcessor::registerPHPFunctions и в xslt юзать php:function() и т.д. Но это пока не вариант. Если же опираться на мнение, что шаблон не имеет права доставать произвольную информацию, а пользоваться только заранее для него сформированной (т.е. cms определяет, что надо выводить такойто шаблон, для которого можно сформировать xml с такимито категориями, такимито информационными блоками и меню), тогда конечно вопросов нет. Но и свободны так ГОРАЗДО меньше.

Использует ли кто-нибудь в качестве основного шаблонизатора [xml-XSLT]? Есть один вопрос.

Начальство неадекватное.

Azadi, и не жаль почти 300$ на неё тратить?

2Yarik Voronov, Eclipse. С помощью плагинов можно сделать что угодно.

http://extjs.com/deploy/dev/examples/grid/array-grid.html

Klopan, а что конкретно не получается?)

Об авторском праве наверное не слышали =)

2rus, зачем создаете информационное загрязнение? Не проще было просто дать ссылки?.. плюс в документации к apache все есть.)

У меня фаербаг работает. Наверно я чтото не так делал Скорость исполнения js выше всех похвал)

^userproductsedit/(.*)$

http://ru2.php.net/manual/ru/language.oop5.php подробнее некуда)