[oodisc] Re: Проект OpenOffice и "решения"

[Dmitry Sorokin]

On Fri, 27 Dec 2002, Raoul & Natalia Nakhmanson-Kulish wrote:

> Allin punchaw qampaq, Dmitry!
>
> В твоем письме от 27 декабря 2002 г., 0:21:09, нам удалось
> вычитать:
>
> DS> А какой?
> Навскидку - три варианта (в порядке убывания серьезности и
> помня, что
> лучше не "вместо", а "вместе" :).
> JavaScript (Mozilla на том стоит, мощная поддержка
> XML/XSLT/DOM);
> OOBasic (для переползающих с Access+MSoffice на GNUe+OOo);
> C# (а почему бы и нет? стандарт открытый, язык сам по себе
> неплохой).
Gnue начиналось и продолжает развиваться как самостоятельное приложение.
Выбран популярный (особенно для unix среды) язык программирования общего
пользования. Про javascript ниже.

>
> DS> Ставка на python была сделана очень давно и те кто
> участвуют в проекте с
> DS> проблемами от этого не сталкивались.
> Тогда хорошо бы прикрутить Python к ООо.
Это да.

>
> DS> Какой то особой интеграции не планировалось. Обмен
> данными? Возможно это
> DS> будет реализовываться средствами Gnue-Integrator (он
> отстает от других
> DS> tools даже в их  0.4.x варианте).
> Обмен данными - вещь хорошая, но мы немного не о том, а,
> например, а
> встраивании форм GNUe в документы OOo или, наоборот,
> формировании
> документов ООо из GNUe. Пример интеграции Access и Word/Excel
> перед
> глазами маячит ;)

Может кто-то еще подключится к дискуссии?
Какие технологии должны поддерживаться со стороны ОО и со стороны
внешнего приложения, чтобы такое стало возможным?

Может быть надо сказать про Gnue Reports.
Оно уже сейчас весь выход отдает в XML к которому затем может
применяться обработка. Например в html или подстановка данных в rtf
шаблон (Правда данные подставились в восьмибитной кодировке, которую ОО
проглотил, а вот ворд не смог - окракозябрил :). Спрашивал у aen куски
ОО-шного кода за ради этого)

[ds на ics SimpleTabulation]$ pwd
/home/ds/cvs/gnue_pure/gnue/reports/filters/SimpleTabulation
[ds на ics SimpleTabulation]$ ls -1
csv.xsl
CVS
fo.xsl
html.xsl
kspread.xsl
text.xsl

Кому надо добавляйте для своих систем.

>
> >> Здорово :) а он может выдавать данные в XML-потоке?
> DS> Для чего это? Поясните?
> Наш насущный хлеб - кроссплатформенные, кроссбраузерные и
> кроссъязыковые Web-интерфейсы к БД поверх HTTP/HTTPS для B2B и
> B2C.

Вы говорите про какие-то существующие системы? URL?

> Требование иметь Mozilla или MSIE для работы с XML/XSL на
> клиентских
> машинах выполнимо гораздо легче, чем требование ставить
> какой-то
> специальный софт.
>
> Соответственно, выдача XML-потока непосредственно из БД по
> HTTP, без
> каких либо дополнительных телодвижений со стороны сервера, не
> только
> существенно упрощает логику и повышает быстродействие на
> серверной
> стороне, но и делает более прозрачной работу на клиенте.

Формы уже сейчас могут забираться по http
Т.е. для варианта cvs-ной девелоперской установки (gfcvs - алиас, для
запуска клиента Forms)
gfcvs <имя формы>
gfcvs http://<путь>/<имя формы>

должно работать.
При работе Forms (интерфейсной части) c application server, протокол
взаимодействия - xmlrpc, как первый вариант и затем будет сделана
pluggable система для добавления других в случае необходимости.

>
> Тем более, что выбор языка интерфейса в нашем случае
> теоретически
> ничем не ограничен - все языково-зависимые данные у нас
> хранятся в
У нас это где? Можно ознакомиться?

> уникоде, как NCHAR в БД и извлекаются с помощью метаданных все
> в тот
> же XML-поток. А потом уже показываются на клиенте как элементы
> интерфейса.
>
> DS> Трех-уровневые архитектуры с бизнес-логикой на уровне
> application
> DS> server-а тоже имеют право на жизнь.
> Бесспорно. Но не отменяют хранимых процедур :)
>
Ага.

> DS> Gnue Designer (единственное средство визуальной разработки
> в Gnue)
> >> Есть ли планы конвергенции Gnue Forms и XUL/XBL?
> DS> Силами существующей сейчас команды это врядли будет
> реализовываться в
> DS> ближайшее время.
> DS> Более реальный вариант появления HTML-драйвера, в
> дополнение к wxpython,
> DS> gtk2 и curses.
> DS> До этого уже были 3 пробные реализации:
> DS> - "сервлетная" версия с использованием webware
> DS> - phpforms
> DS> - jsforms (java-script)
> DS> , сейчас видимо будет четвертая.
> Предлагаем еще один путь - использование XSLT для
> преобразования Gnue
> Forms из native XML как в XUL-, так и в HTML-формы. И вот тут
> бы
> внесто Python очень пригодился бы JavaScript - не как язык
> построения
> форм, а как язык обработки событий.
>

Я думаю что именно так будут получаться HTML формы в разрабатываемом
HTML (web) драйвере. В этом случае вся существующая питоновская обработка останется
на сервере, а для обработки событий и JavaScript может появиться. Общение
с серверной стороной опять же вполне возможно через xmlrpc.
Как похожий пример http://openthought.net


Можем ли мы согласиться с выводом, что Gnuenterprise на уровне
архитектуры (построения системы) располагает возможностями для постояния
систем и для интеграции с другими системами в соответствии с пунктами
вашего Wish List'а?

Тогда уже можно переходить к более мелким техническим деталям :)

С уважением,
Дмитрий Сорокин