Ответ

G_Z 02.11.2013 13:52 / 02.11.2013 14:03

1. реализовать несложно, но я не уверен, что это стоит делать.

Почему?

Совместимость не страдает — опция дополнительная, а пробельные символы — бич списков извне, к примеру, введенных невнимательными редакторами. Из-за необходимости их подчищать приходится отказываться от удобного split и городить многострочные конструкции с обрезкой.

2. … в предложенном варианте для каждой записи будет выполняться два "тела", что хуже, чем проход по таблице с помощью menu с формированием внутри $.[код, формирующий ключ][код, формирующий значение]

Как я понимаю, объём выполняемых действий примерно одинаков — хоть сразу выполнить два тела на запись, хоть отдельно их же при menu, — неясно, чем второй вариант лучше. Во втором даже лишний проход по таблице получается.
При этом, первый позволяет полностью исключить 3+ строк кода, иногда, при сложном формировании ключей и значений, много больше.

3. я не "в струе" и не очень понимаю, что требуется

При вызове parser://method/что-либо «что-либо» передаётся параметром в @method. Функция document() — чтение внешнего XML-документа или нескольких документов по URI. Соответственно, имя метода, и передаваемый параметр должны соответствовать URI и не содержать в явном виде неразрещённых в нём символов. С именем метода вопросов нет, к ним ещё предъявляет требования и сам Parser, но вот передавать хочется всевозможные данные, хотя бы произвольный текст, а как только там встречается пробел — вызов просто не уходит и приходится делать наколенное кодирование-декодирование.

Я к сожалению не знаю как оно изнутри устроено, видимо вызов идёт из libxml, и на него особо не повлиять. Суть в том, что если делать перед вызовом метода URL-encode параметра и по получении парсером, и до вызова метода, URL-decode, то передавать можно будет намного более разнообразные данные, возможно даже фрагменты XML-дерева с переводами строк.

Пример: https://dl.dropboxusercontent.com/u/6795309/temp/parser-protocol.zip

---