Согласен, насчет организации,
но for-each тоже не может выступать в качестве универсального решения, поскольку в таком случае теряется возможность переопределения правил для специфичных случаев
Идея действительно такая как было сказано выше.
Прирост производительности — порядка 20%(зависит от XSLT)
Жаль только что похоже проект остановился в развитии еще несколько лет назад
«Причём, если для шаблона используется mode, то дочерние узлы тоже будут преобразовываться с этим mode»
mode не наследуется его необходимо принудительно прописать для apply-templates, вне зависимости от mode самого шаблона. Может поведение в разных парсерах и отличается, но для libxslt это так.
В начале статьи вы пишете
"[проект] как я думаю может быть полезен многим из вас"
а теперь говорите что это решение для частного случая с причудливыми исходными требованиями :)
но только не понятно зачем реализовывать это на уровне XSLT
а не с помощью того же серверного Javascript, если уж на то пошло,
генерируя XML и преобразовывая его в другой формат используя XSLT
Так и не понял ответа на вопрос «Зачем это нужно ?»
Для того чтобы расширить возможности XSLT существует библиотека EXSLT
Добавление еще каких то скриптовых возможностей внутрь XSLT по моему противоречит самой концепции использования связки XML/XSLT
понятие "переводчик" уместно когда речь идет о десктоп системе с локализациями(переводами) языкозависимых констант(кнопки, тексты)
и вряд ли применимо для web проекта где "переводчиков" может быть несколько, и они никак не связаны с разрабочиками системы, а многоязычным должно быть само содержание сайта.
Пробовал использовать gettext в CMS.
Основной довод против - сложность интеграции редактора переводов с админчастью.
Писать свой web frontend для редактирования .po файлов - изобретать велосипед. Интегрировать существующие в свой проект - сходу не удалось.
Использовать off line редактор в моем случае - нельзя.
Пришлось отказаться от этой идеи.
но for-each тоже не может выступать в качестве универсального решения, поскольку в таком случае теряется возможность переопределения правил для специфичных случаев
по практическому применению XSLT (временные деревья) здесь
В целом он конечно больше ориентирован на опытных разработчиков.
Идея действительно такая как было сказано выше.
Прирост производительности — порядка 20%(зависит от XSLT)
Жаль только что похоже проект остановился в развитии еще несколько лет назад
Правда, смутила фраза
mode не наследуется его необходимо принудительно прописать для apply-templates, вне зависимости от mode самого шаблона. Может поведение в разных парсерах и отличается, но для libxslt это так.
Насчет толку ноль — неправда
производительность в конкретном моем случае повышается где то на 10%
честно говоря у меня сложилось то же самое мнение — JFF
В начале статьи вы пишете
"[проект] как я думаю может быть полезен многим из вас"
а теперь говорите что это решение для частного случая с причудливыми исходными требованиями :)
но только не понятно зачем реализовывать это на уровне XSLT
а не с помощью того же серверного Javascript, если уж на то пошло,
генерируя XML и преобразовывая его в другой формат используя XSLT
Для того чтобы расширить возможности XSLT существует библиотека EXSLT
Добавление еще каких то скриптовых возможностей внутрь XSLT по моему противоречит самой концепции использования связки XML/XSLT
что нельзя производить внуков от Object
Тогда действительно все правильно :)
class MyRectangle extends Rectangle{
function dummy(){
//getHeight() не вызывается
var_dump($this->height);
}
}
$mr = new MyRectangle();
$mr->dummy();
и вряд ли применимо для web проекта где "переводчиков" может быть несколько, и они никак не связаны с разрабочиками системы, а многоязычным должно быть само содержание сайта.
Основной довод против - сложность интеграции редактора переводов с админчастью.
Писать свой web frontend для редактирования .po файлов - изобретать велосипед. Интегрировать существующие в свой проект - сходу не удалось.
Использовать off line редактор в моем случае - нельзя.
Пришлось отказаться от этой идеи.
форуме
http://ru.wikibooks.org/wiki/Ruby/%D0%98%D0%B4%D0%B5%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F