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

Raoul & Natalia Nakhmanson-Kulish myr на south.net.ru
Пт Дек 27 12:49:32 MSK 2002


Allin punchaw qampaq, Dmitry!

В твоем письме от 27 декабря 2002 г., 0:21:09, нам удалось вычитать:

DS> А какой?
Навскидку - три варианта (в порядке убывания серьезности и помня, что
лучше не "вместо", а "вместе" :).
JavaScript (Mozilla на том стоит, мощная поддержка XML/XSLT/DOM);
OOBasic (для переползающих с Access+MSoffice на GNUe+OOo);
C# (а почему бы и нет? стандарт открытый, язык сам по себе неплохой).

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

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

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

Соответственно, выдача XML-потока непосредственно из БД по HTTP, без
каких либо дополнительных телодвижений со стороны сервера, не только
существенно упрощает логику и повышает быстродействие на серверной
стороне, но и делает более прозрачной работу на клиенте.

Тем более, что выбор языка интерфейса в нашем случае теоретически
ничем не ограничен - все языково-зависимые данные у нас хранятся в
уникоде, как 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 - не как язык построения
форм, а как язык обработки событий.

__
Счастливой Пачи - Myr AKA Manko
PGP DH/DSS Key ID 0x11807439, Fingerprint dhgGjJy7vbTzfdp+97vZ8hGAdDk=





Подробная информация о списке рассылки Oo-discuss