Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Несколько месяцев назад я обещал кому-то показать работающий крупный сайт с XSLT на стороне клиента. Однако ни черта у меня не вышло, в связи с JavaScript-related заморочками (впрочем, сайт тот загнулся сам по себе). А жаль, с точки зрения нагрузки на сервер этот вариант потянул бы на идеальный, если бы оказался действительно работоспособным.

Возможно, вместо XSLT на стороне клиента лучше воспользоваться JSONT, можно глянуть примеры использования.

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

Здравствуйте, c-smile, Вы писали:

CS>Какое угодно. Только human readable.
При правильном использовании для правильных целей придумать что-то более человекочитаемое и столь же уневерсальное очень трудно.

CS>Статические преобразования не всегда эффективны.
CS>Есть ситуации когда процедурный подход позволяет редуцировать complexity.
CS>Иногда с O(n*n) до O(n). Все в общем как всегда — все хорошо что в меру.
Пример в студию.

Здравствуйте, Sinclair, Вы писали:

S>Чисто теоретически, умная среда исполнения должна уметь компилировать также и цепочку XSLT преобразований.

Гы, вот именно, что теоретически, да умная. Мы про PHP говорим или где?

Здравствуйте, WolfHound, Вы писали:

CS>>Какое угодно. Только human readable.
WH>При правильном использовании для правильных целей придумать что-то более человекочитаемое и столь же уневерсальное очень трудно.

Что в данном случае имеется в виду?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, c-smile, Вы писали:

CS>>Какое угодно. Только human readable.
WH>При правильном использовании для правильных целей придумать что-то более человекочитаемое и столь же уневерсальное очень трудно.

Коэффициенты возможностей перемножаются:

P(При правильном использовании) * P(для правильных целей)

Даже при условии 50 на 50 в обоих случаях твоё утверждение истинно с возможностью 0.25

CS>>Статические преобразования не всегда эффективны.
CS>>Есть ситуации когда процедурный подход позволяет редуцировать complexity.
CS>>Иногда с O(n*n) до O(n). Все в общем как всегда — все хорошо что в меру.

WH>Пример в студию.

Легко:

http://www.tkachenko.com/blog/archives/000268.html

Straightforward declarative solution = O(maxDepth*maxDepth*n) with worst case O(n*n)
Procedural = O(n).

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>!!!!!! Дали бы нам эти машины лет 20 — 25 назад !!!!

Новый процессор Intel Pentium позволяет выполнять до 10 миллионов сбоев в секунду!

Здравствуйте, c-smile, Вы писали:

Со всем до этого согласен.

CS>Вообще это маразм использовать язык описания данных в роли процедурного. Или нет?

Он не процедурный. Он специализированный, функциональный.

Здравствуйте, c-smile, Вы писали:

CS>Есть ситуации когда процедурный подход позволяет редуцировать complexity.
CS>Иногда с O(n*n) до O(n). Все в общем как всегда — все хорошо что в меру.

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

Здравствуйте, Lloyd, Вы писали:

L>Второй и третий этап делать на этапе деплоймента сайта. На выходе должно получиться большое количество xslt первого типа.

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

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Тупо свести <ft:form> к <x:call-template name="f:form"> не выходит, потому как внутри <f:form> генерируется дополнительный контент: <table>.

Честно говоря, не очень понял.

Здравствуйте, AndrewVK, Вы писали:

ДГ>>Тупо свести <ft:form> к <x:call-template name="f:form"> не выходит, потому как внутри <f:form> генерируется дополнительный контент: <table>.

AVK>Честно говоря, не очень понял.

В некоторых случаях бывает удобно делать так:

<x:template match="a:something" name="a:something">
    <x:with-param name="attr" select="@attr"/>
        <x:if test="$attr='...'">
            ...
        </x:if>
</x:template>

В этом случае данный шаблон можно вызывать двумя способами:

<a:something attr="..."/>

и

<x:call-template name="a:something">
    <x:with-param name="attr" select="..."/>
</x:call-template>

Первый способ выглядит гораздо приятнее, поэтому им я при возможности и пользуюсь. Тот факт, что я выполняю второй проход над всем сгенерированным контентом (см. <template match="/"/> в корневном сообщении), обеспечивает его полное разворачивание. Я это использую, например, при генерации контролов для постраничной навигации в списках. Примитивы выглядят так:

<!-- Overridable. -->
<x:template name="p:pfirst-text">&lt;&lt;</x:template/>

<x:template match="*" mode="p:first" name="p:first" xmlns:p="http://dimgel.ru/xmlns/paginator">
    <x:param name="x" select="."/>
    <x:choose>
        <x:when test="$x/@pageNo &gt; 1">
            <a href="{/*/sys/paths/requestUriPage}1"><x:call-template name="p:first-text"/></a>
        </x:when>
        <x:otherwise>
            <span class="disabled"><x:call-template name="p:first-text"/></span>
        </x:otherwise>
    </x:choose>
</x:template>

Здесь входной элемент $x имеет атрибуты @pageNo, @pageCount, @pageSize, @rowCount (и дочки <r>, каждая дочка потом мапится в строку таблицы-списка). Код, собирающий эти примитивы в кучу под конкретный дизайн конкретного сайта выглядит, например, так:

<x:template match="*" mode="pagination">
    <table class="pagination"><tr>
        <td class="pl">
            <x:value-of select="'страница'"/>
            <x:call-template name="p:first"/>
            <x:call-template name="p:prev"/>
            <span class="pmargins">
                <x:call-template name="p:numbers"/>
            </span>
            <x:call-template name="p:next"/>
            <x:call-template name="p:last"/>
        </td>
        <td class="pr">
            <x:value-of select="'строк на странице'"/>
            ....
        </td>
    </tr></table>
</x:template>

Здесь я использую <x:call-template name="p:first"> вместо <p:first/>, чтобы не увеличивать требуемый уровень вложенности обработки, поскольку вызов <x:apply-templates select="..." mode="pagination"/> может использоваться, например, из какого-нибудь <adm:pagedlist .../>. Хотя на данный момент этого нет, и мог бы и написать компактнее и красивше:

<x:template match="*" mode="pagination">
    <table class="pagination"><tr>
        <td class="pl">
            <!-- это кстати чистое пижонство, чтобы в режиме <x:output indent="no"/> 
                весь результирующий HTML был в одну строку, без \n -->
            <x:value-of select="'страница'"/>  
            <p:first/>
            <p:prev/>
            <span class="pmargins"><p:numbers/></span>
            <p:next/>
            <p:last/>
        </td>
        <td class="pr">
            <x:value-of select="'строк на странице'"/>  <!-- ну и это тоже :) -->
            ....
        </td>
    </tr></table>
</x:template>

Как провернуть такой фокус в случае <ft:form>, не понятно, потому что и <ft:form>, и подавно <f:form> получают из вызывающего контекста произвольные атрибуты и контент. Они выполняют <x:apply-templates/> на своих дочках, при этом все не-специальные элементы, атрибуты и текстовые узлы просто копируются в выходной документ. Никаких ограничений. Не писать же что-то вроде следующего:

<x:template match="ft:form">
        <x:call-template name="f:form">
          <x:with-param .../>   <!-- ВСЕ возможные и невозможные атрибуты -->
            ...
            <x:with-param name="content">
                <tr>
                    <th>Title:</th>
                    <td><x:call-template name="f:text">
                        <x:with param .../>  <!-- опять ВСЕ возможные атрибуты -->
                        ...
                    </x:call-template></td>
                </tr>
                ...
        </x:call-template>
</x:template>

Гы, вот тут без косвенности. Только я её мама писать такое.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>>>Тупо свести <ft:form> к <x:call-template name="f:form"> не выходит, потому как внутри <f:form> генерируется дополнительный контент: <table>.

AVK>>Честно говоря, не очень понял.

ДГ>В некоторых случаях бывает удобно делать так:

В общем, используя свои элементы вместо <x:call-template/> и <x:apply-templates/>, я повышаю читабельность исходников и отвязываюсь от структуры входного документа (уменьшаю зависимость генерирующего XML кода от дизайна). Ценой необходимости дополнительных проходов.

ДГ>потому что и <ft:form>, и подавно <f:form> получают из вызывающего контекста произвольные атрибуты и контент. [...] Никаких ограничений.

Выделить "произвольные" жирным забыл.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>В этом случае данный шаблон можно вызывать двумя способами:

ДГ>

ДГ><a:something attr="..."/>
ДГ>

ДГ>и

ДГ>

ДГ><x:call-template name="a:something">
ДГ>    <x:with-param name="attr" select="..."/>
ДГ></x:call-template>
ДГ>

ДГ>Первый способ выглядит гораздо приятнее, поэтому им я при возможности и пользуюсь.

Т.е. единственная причина, по которой у тебя куча проходов, это то, что тебе кажется, что match выглядит приятнее call-template???

Здравствуйте, AndrewVK, Вы писали:

AVK>Т.е. единственная причина, по которой у тебя куча проходов, это то, что тебе кажется, что match выглядит приятнее call-template???

Я в самом конце написал насчёт произвольного контента и атрибутов у <f:form> с невозможностью ввернуть это всё в call-template — это и есть главная причина. А раз уж я ввязялся в двухпроходную обработку, было бы глупо не использовать вытекающие из неё удобства.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Я в самом конце написал насчёт произвольного контента и атрибутов у <f:form> с невозможностью ввернуть это всё в call-template — это и есть главная причина.

Тогда опять непонятно. Только не надо, плиз, приводить опять горы кода.

ДГ> А раз уж я ввязялся в двухпроходную обработку, было бы глупо не использовать вытекающие из неё удобства.

Тогда с самого начала — зачем тебе вообще понадобилась двухпроходная обработка? Насколько я понял описанную задачу — все спокойно решается одним проходом без каких либо ухудшений читаемости.

Здравствуйте, AndrewVK, Вы писали:

AVK>Тогда опять непонятно. Только не надо, плиз, приводить опять горы кода.

AVK>Тогда с самого начала — зачем тебе вообще понадобилась двухпроходная обработка? Насколько я понял описанную задачу — все спокойно решается одним проходом без каких либо ухудшений читаемости.

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

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Я с самого начала написал достаточно прямолинейно: покажите мне такое решение.

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

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

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Только не надо, плиз, приводить опять горы кода.

Гы-гы-гы. Вот по факту мои усилия оказываются направленными на войну с этим б#$&ским языком, в котором любая попытка программировать в процедурном стиле через call-template оборачивается горами кода.

Вот смотри, ещё философское соображение: я писал в корневом сообщении, что входной XML у меня неструктурированный, чтобы не привязывать php-код к дизайну. Получается, что первым проходом я компенсирую это отсутствие структуры на входе, генерируя структуру без данных. А на втором проходе делаю собственно то, для чего XSLT удобен — выполняю трансформацию на готовой структуре (т.е. перегоняю из пустого в порожнее... замечательный язык). А чтобы сделать это всё за раз, и не увязнуть в горах кода... Я начинаю уже подумывать, что Smarty — не такая уж и плохая вещь...

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Гы-гы-гы. Вот по факту мои усилия оказываются направленными на войну с этим б#$&ским языком

Ты поаккуратнее с матюками.

ДГ>, в котором любая попытка программировать в процедурном стиле через call-template

С чего ты взял, что call-template это процедурный стиль?

ДГ> оборачивается горами кода.

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

ДГ>Вот смотри, ещё философское соображение: я писал в корневом сообщении, что входной XML у меня неструктурированный, чтобы не привязывать php-код к дизайну.

Непонятно.

Здравствуйте, AndrewVK, Вы писали:

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

Аааа... Так весь вопрос в том, что тебе читать лениво? Так бы и сказал. Забей, никакой проблемы у меня нет, меня всё устраивает. А приводил я все эти горы кода на случай "вдруг кому-то интересно". Сложных и неоднозначных примеров использования XSLT в сети я не видел (вернее, видел главы из книги на xmlhack.ru, но там заумь иного рода), вот и надеялся вызвать людей на обсуждение.