Ответ

kirill v.2 24.03.2005 17:45

Сорри, когда писал - эту мысль еще не видел. Да, концептуально - примерно то же.

меня беспокоит одно: люди, которые будут пользоваться этим, должны будут разобраться ещё и в XUL. знаю, что это просто, но знаю, что люди разбираться в чём-то не хотят

По моему не есть основная задача упразднить всякий труд :) К тому же мне почему-то кажется, что разобраться в XUL может в конечном счете оказаться проще, чем в соответствующих классах Parser для GUI, если встроить в Parser то, что сейчас умеет XUL/XPCOM :) Поскольку XUL и все, что вокруг него, изначально проектировался для работы именно с виджетами GUI, а Parser - это же интерпретатор, не более ? ИМХО, не стоит мешать мух с котлетами.

Скрещивание XUL с Parser мне пока представляется примерно так, как Вы это описали в мысли про "script language=Parser3":
1. Написание мозилловского компонента xpt (C++), реализующего протокол parser://
2. При запросе скриптом из XUL по этому протоколу - скрипт обрабатывается интерпретатором Parser3 (как сейчас при использовании в консоли, только без консольного окна).
3. Результат отдается вызывающему методу. Наиболее удобен будет возврат plain/xml и/или RDF, хотя наверняка можно предусмотреть интерфейсы, возвращающие непосредственно датасеты всякие etc. Но XML/RDF и так вполне достаточно для любых задач.

Это сразу позвозяет:
1. Лазить в ODBC/MySQL/.../files_datasources непосредственно из XUL, минуя сервер. Это основной положительный момент.
2. Использовать Parser как обертку для запуска внешних приложений (в XUL есть nsILocalFile.run(params), но как получить результат из stdout - загадка до сих пор.
2. Загружать данные из удаленных источников, обходя ограничения на безопасность при запуска XUL вне chrome (некритично для XUL Runner, но знаю, что в ряде случаев будет очень полезно).
3. Скорее всего - решить очень многие проблемы при реализации админки не как standalone/chrome, а как Remote XUL, в том числе генерировать Parser собственно XUL-документы, описывающие формы GUI-интерфейса.

Простейший (и тупейший) пример - с заполнением списка страниц сайта в XUL-Tree через указание RDF datasources:

Конструкция XUL:
<tree id="pGrid" enableColumnDrag="true" seltype="single" datasources="parser:///path/to/parser_script" ref="http://SF/xsite/tree" flags="dont-build-content" flex="1" ondblclick="editPageParams(event)" style="margin:2px;">
... тут описание колонок и строк дерева, см. xulplanet.com ...
</tree>

скрипт [z:]/path/to/parser_script возвращает заголовки content-type text/rdf и собственно XML-RDF описание структуры сайта в любой удобной форме, получая данные о структуре сайта непосредственно из базы или откуда угодно, хоть с удаленного хоста (впрочем в последнем случае можно и без протокола parser:// обойтись, интересует именно доступ к базе на локальной машине/сети без запуска там Apache иже с ним).

В результате имеем интерфейсный виджет с деревом страниц, запоминанием состояния скрыта/открыта ветка дерева и т.п. и т.д. Реализовать такой виджет срествами самого Парсера - это по моему нереальная задача, которую и решать не стоит, уж тем более под win32 only :) XUL - кроссплатформенный, все-таки.

Еще пример - тут полная аналогия с script lang=parser3:
В XUL-документе есть <iframe src="parser://part/to/script"/> В оном фрейме можно видеть выдачу скрипта (хоть HTML со всеми вытекающими формами и приемами, хоть опять XUL). Если кому то удобно делать формы на Parser - плиз. В этом случае из XUL можно изучить 2 тега (window и iframe :) Собственно, моя первая админка работала именно так, XUL приложение заменяло браузер, но нужно же было все равно локальный сервер запускать. В данном случае - не нужно. Это, по моему, самый быстрый путь для не желающих ковыряться в XUL/XPCOM.

Дополнительно приходит в голову:
- Написание GUI для тестов модулей. В этом случае локальный сервер и на фиг не нужен, а приходится его только за ради GUI в HTML запускать.

И т.п. Вообще-то тема очень интересна, хочется верить, что Parser продолжит развитие, а то я уже было совсем собрался со своми XUL в PHP5 мигрировать :) Если тема будет иметь продолжение - с удовольствием поучаствую в процессе как мимнимум тестером или кем угодно еще в меру скромных сил.

---