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

[Dmitry Sorokin]

On Thu, 26 Dec 2002, Raoul & Natalia Nakhmanson-Kulish wrote:


> >> это называется так, сокращенно FEDT).
> DS> Если рассматривать GnuEnterprise то по пунктам:
> Посмотрели :) действительно, крайне интересный проект.
>
> Смущает только использование Python. Не спорим, язык мощный и
> гибкий, но в

А какой?
Ставка на python была сделана очень давно и те кто участвуют в проекте с
проблемами от этого не сталкивались.
Часто задается вопрос почему не Java.
Хотя бы потому, что это официальный проект gnu.org


> перспективе хотелось бы, чтобы и OOo, и FEDT использовали бы
> единый
> язык. Планируется ли интеграция GnuEnterprise и OOo?
>

Какой то особой интеграции не планировалось. Обмен данными? Возможно это
будет реализовываться средствами Gnue-Integrator (он отстает от других
tools даже в их  0.4.x варианте).
Оговаривалась возможность выбора языка для написания триггеров и
модулей. В будущем.
Наверное подобные же процессы будут происходить и на стороне OO.

Слышал очень хорошие отзывы о возможности использования Python в
Gnumeric



> DS> Возможно несколько специализированный, но DB Abstraction
> Layer
> DS> есть.
> Здорово :) а он может выдавать данные в XML-потоке?
>
Для чего это? Поясните?
Если то, что я понимаю, то будет реализовываться в Integrator-е.


> DS> Поскольку с хранимыми процедурами переносимость можно
> DS> потерять следующий этап это перенос бизнес логики на
> application
> DS> server (в стадии написания-переписывания).
> Нам не кажется, что это оправданно. Проблемы с хранимыми
> процедурами
> специфичны AFAIK только для MySQL, и для нее можно было бы
> придумать
> какой-нибудь workaround (например, подстановка тела процедуры
> как
> макроса). Все-таки процедуры - слишком мощное средство,
> имеющее в большинстве СУБД существенно большее быстродействие,
> чем
> просто эквивалентный запрос.
>

Трех-уровневые архитектуры с бизнес-логикой на уровне application
server-а тоже имеют право на жизнь.
Gnue Designer (единственное средство визуальной разработки в Gnue)
развивался из потребностей Gnue Forms. Возможность описания триггеров (с
подсветкой синтаксиса) появилась лишь в последнее время. Поддержка
introspection использовалась, чтобы по существующей базе с помощью
визарда построить форму.

Базу пока надо проектировать отдельными средствами (руки?). Gnue никаких
ограничений тут не накладывает.

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

, сейчас видимо будет четвертая.

Неудача предыдущих в том, что они делались в отрыве от работы основной
команды и во многом получалось переписывание (новая реализация клиента
Forms под ту или иную технологию) вместо написания дополнительного
драйвера UI.

Может и к XUL будет проще вернуться несколько позже.


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