PHP и кастомизируемый XSLT-процессор

Написать свой биндинг к libxslt. Других вариантов не вижу. PHP - не Java, много разных xslt процессоров не имеет. Так что не с чего особо выбирать.

Или код для трансформации переписать на другом языке, тоже вариант.

Написать свой биндинг к libxslt.

Это php-devel, ZEND, вот это все?

Ага:) Другого варианта к сожалению не вижу. XSLTProcessor - лучшее, что есть в стане PHP.

Так а все же, вот это апи: http://php.net/manual/en/book.xslt.php - оно что, совсем вымерло? Его реально поднять на последнем php/apache/centos/и т.д., или не стОит?

Если сможете портировать его на PHP5 - то почему бы и нет? Только дело это муторное, и долгое. Нужно будет вам в потрохах php-devel и ZEND ковыряться. Или использовать для проекта PHP4, если есть желание. Думаю что вам стоит задуматься над вопросом: а так ли нужно использовать именно XSLT? Есть Twig, Smarty. Большинство проектов не используют xslt без крайней необходимости, юзают чистый PHP или шаблонизаторы.

Да, да, именно XSLT, т.к. это ВОТ ОН, ВОТ ОН, ПРОЦЕССОР МОЕЙ МЕЧТЫ!!1

Нашел вот такую feature request: https://bugs.php.net/bug.php?id=35580

Submitted: 2005-12-07 09:35 UTC Status: Open

Пичялька :)

Печально. Но разрабы PHP не сильно интересуются такими вещами как XSLT. Данный препроцессор используют автивно разработчики на Java, и некоторые фаны node.js. В php данный подход не прижился. Равно как в Ruby и Python. Шаблонизаторы с полее простым синтаксисом и более простой архитектурой рулят на в проектах на данных ЯП. Да и мало специалистов знает XSLT на хорошем уровне. Отсюда и недоверие к нему, и нежелание использовать его в различных фреймворках и CMS. С тем же smarty человек может освоиться за пару часов. Хорошо изучить XSLT получится за три недели, месяц напряженных занятий. Отсюда и такая любовь к простым шаблонизаторам, и игнорирование XSLT. Возможности у XSLT конечно уникальные, заменить его при сложных трансформациях может только код на JS манипулирующий с DOM-елементами при помощи специальных библиотек. Но вы же не FB2 конвертить в EPUB собрались? Или пишете систему документооборота? Для простого шаблонизатора в среднем по величине Web-проекте просто нет смысла юзать XSLT. Это как из пушки по воробьям палить.

Да, я вот уже тоже посматриваю в сторону Java, особенно с учетом того что там, в отличие от php, есть полноценный XSLT 2.0.

От XSLT уже отказаться не смогу, т.к., как вы правильно сказали, это уникальная технология, особенно в связке с офигенными возможностями XPath. За ~5 лет я привык к нему настолько, что отлипнуть уже не получится (это с учетом того, что я периодически просматриваю другие шаблонизаторы). Ну и движком пользуюсь только я сам, поэтому проблемы сложности обучения у меня не возникает.

XSLT удовлетворяет всем моим требованиям: простота (в моем понимании), мощность функционального разнообразия, производительность, семантический симбиоз с XHTML (шаблон, данные и выхлоп - все в одном диалекте), легкость мэйнтанса (легко читаю код, написанный несколько лет назад), и т.д.

Мне тоже нравится XSLT. Особенно вторая версия. Но её только в Java и .NET и используют. Там, где из одного набора данных получают HTML, XHTML, и PDF. А также Open Office Doc и т.п. Java для вашего приложения будет предпочтительней, чем скриптовые ЯП. Да и скорость работы, качество библиотек и их многообразие у данной платформы просто поражают воображение.