Ответ
G_Z 02.03.2008 22:54
Додуматься до вызова вполне возможно: идёт вызов внешнего документа.
Об этом в документации написано.
А как путь к документу формируется — дело десятое, в данном случае, это конкатенция.
В документации упор сделан на хранение шаблонов в БД, т.к. для этого parser:// и задумывался, с небольшими вариациями.
Пока подобный функционал позволяет лишь поэкспериментировать и прикинуть реальные возможности.
Я делал разные вещи, в качестве эксперимента:
1. upper/lower строки
2. random
3. node-set
4. обработка и сохранение BASE64-картинок в XML-представлении вордового документа.
Кроме 3 пункта сделал все, но с органиченным функционалом, т.к. немедленно упёрся в органичения URL и символов имён методов/параметров.
Эти эксперименты показали, что для самых, казалось бы, тривиальных вещей типа upper/lower нужно писать громоздкие обёртки, как с отсылающей строны (на XSL), так и с принимающей («разбиратор» пришедшего на Парсере).
Вариант с BASE64 вообще практически нереализуемый передачей строки, там пришлось передать некий «указатель» (путь до узла, имя и значения уникального атрибута) и потом DOM-методами разбирать обрабатываемый документ, выуживая узел и его энкоденное значение.
Оно работает, но только в тестовых условиях и совсем неэлегантно.
Node-set по сложности реализации примерно сопоставим с BASE64.
Только random — простой, т.к. принимает на вход число и отдаёт число, без хитростей.
Эти сложности и заставили поднять вопрос о полноценных расширениях.
Код не привожу, т.к. он тестовый и особого смысла показывать его не вижу.
Речь не о том как исхитриться и заставить работать сложные вещи с применением ограничений parser://, а о том, что ограничения нужно убирать, дабы открылось простраство для манёвра.
Если получится задуманное реализовать можно будет статейку-пример написать, но это потом.