Automation в OpenOffice

http://www.i-rs.ru/article/articleview/145/1/55
http://api.openoffice.org/index.html
http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html

Заодно и ты ответь на вопрос: "нахрена?" Насмотрелся, как в виндах приделывают автоматизацию к мс-офису и захотел сделать такое же в юниксах?

Лучше обдумай, чего тебе надо и постарайся обойтись без костылей.

PS. Скачать Qt можно с сайта производителя: http://trolltech.com

> Лучше обдумай, чего тебе надо и постарайся обойтись без костылей.

Ты не догнал :)

Это "не с костылями" - это "базовый набор": выдать юзеру необходимую информацию, а "костыли" потом пусть сам юзер "рисует" - ты заманаешься реализовывать все возможности эл. таблиц по произвольной обработке и анализу информации, а с шаблонами неплохо всякие документы плодить, которые _очень часто_ надо слегка "рихтовать" вручную после генерации.

Если же всё известно - отчёт строго такой формы и ни шагу в сторону - да, такая связка будет излишней.

> ты заманаешься реализовывать все возможности эл. таблиц по произвольной обработке и анализу информации

Электронная таблица -- не лучший выбор для "произвольной обработки и анализа информации".

Да, к тому же, формат опенофисных документов открыт, можно документ генерить и без взаимодействия с самим опенофисом, а потом в опенофисе его только открывать.

Хотя смотря что нужно автору... Может это лабораторная по автоматизации :)

> Электронная таблица -- не лучший выбор для "произвольной обработки и анализа информации".

Но это может быть оптимальным выбором при определённых обстоятельствах.

> Да, к тому же, формат опенофисных документов открыт, можно документ генерить и без взаимодействия с самим опенофисом, а потом в опенофисе его только открывать.

Это может оказаться _намного_ сложнее, чем "заполнение" шаблонов. Да и "сопровождение" шаблонов проще в некоторых случаях.

>> Электронная таблица -- не лучший выбор для "произвольной обработки и анализа информации".

> Но это может быть оптимальным выбором при определённых обстоятельствах.

Давайте не будем скатываться на философские вопросы. Хотелось бы просто услышать от топикстартера, что он собирается делать, а там уже обсирать^W обсуждать его выбор. :)

> Давайте не будем скатываться на философские вопросы. Хотелось бы просто услышать от топикстартера, что он собирается делать, а там уже обсирать^W обсуждать его выбор. :)

...что говорит о том, что вы уже предвзято относитесь к его выбору :D

Нет, если надо под каждый "чих" заказчика изображать бурную деятельность и драть с него за это кучу бабла - то да, лучше всё делать программно. А когда это некоторая автоматизация собственной деятельности или "соседнего отдела", то очень хочется сделать так, чтобы потом приставали как можно меньше

>> Давайте не будем скатываться на философские вопросы. Хотелось бы просто услышать от топикстартера, что он собирается делать, а там уже обсирать^W обсуждать его выбор. :)

> ...что говорит о том, что вы уже предвзято относитесь к его выбору :D

Нет, просто потому, что это ЛОР :)

> Нет, если надо под каждый "чих" заказчика изображать бурную деятельность и драть с него за это кучу бабла - то да, лучше всё делать программно. А когда это некоторая автоматизация собственной деятельности или "соседнего отдела", то очень хочется сделать так, чтобы потом приставали как можно меньше

Хм... Пользоваться кривой реализацией виндоксотыля под названием COM, всунутой саном в опенофис через qt и тем самым пытаться автоматизировать свою работу?

Вероятно, я чего-то не понимаю, но мне сгенерить документ с использованием sed/grep/awk/чего-нибудь ещё несравнимо легче. Да и юниксвейнее оно как-то.

> Пользоваться кривой реализацией виндоксотыля под названием COM, всунутой саном в опенофис через qt и тем самым пытаться автоматизировать свою работу?

Ну, я думаю это действительно слишком :) Но зачем COM? Или это вы так "любя" об UNO?

Ведь можно использовать "родной" сановский UNO-интерфейс для того-же c++ (раз уж речь идёт о Qt) - в этом я ничего кривого не вижу.

> Вероятно, я чего-то не понимаю, но мне сгенерить документ с использованием sed/grep/awk/чего-нибудь ещё несравнимо легче. Да и юниксвейнее оно как-то.

Ха, я бы посмотрел, сколько времени бы у ваз заняло изучение форматов ОО и каких размеров были бы ваши программы по генерации документов/таблиц со сложным форматированием, графиками и т.п. Опять-же, фактически самому писать часть функциональности уже реализованной и доступной "извне" (разве что не через динамические библиотеки) - это "тру юниксвей"? Вы меня удивляете...

> Ведь можно использовать "родной" сановский UNO-интерфейс для того-же c++ (раз уж речь идёт о Qt) - в этом я ничего кривого не вижу.

Кривость в ненужном усложнении.

>> Вероятно, я чего-то не понимаю, но мне сгенерить документ с использованием sed/grep/awk/чего-нибудь ещё несравнимо легче. Да и юниксвейнее оно как-то.

> Ха, я бы посмотрел, сколько времени бы у ваз заняло изучение форматов ОО и каких размеров были бы ваши программы по генерации документов/таблиц со сложным форматированием, графиками и т.п. Опять-же, фактически самому писать часть функциональности уже реализованной и доступной "извне" (разве что не через динамические библиотеки) - это "тру юниксвей"? Вы меня удивляете...

Формат опенофисных файлов: зазипованный набор xml-ек. Кроме того, опенофису вполне можно скормить html, csv и т.д. Так что не вижу проблем с форматом.

Хотя есть одно принципиальное различие: автоматизация(будь то в опенофисе или в мс-офисе или где ещё) подразумевает выполнение той же последовательности действий, которую делала бы секретарша, набивая документ(написать заголовок, выделить, указать тип "заголовок 1"...). Генерация же сразу в файл подходит с качественно иной стороны -- со стороны структуры документа и его содержимого(<h1>заголовок</h1>).

> Кривость в ненужном усложнении.

Усложнении чего? Только не надо говорить, что ОО не нужен :)

> Формат опенофисных файлов: зазипованный набор xml-ек.

%ля, ну не надо считать меня идиотом! То, что там XML ещё не значит, что его так просто генерить. Попробуйте на досуге.

> Кроме того, опенофису вполне можно скормить html, csv и т.д. Так что не вижу проблем с форматом.

Хрен редьки не слаще, если нужны шаблоны, которые заполняются автоматически и доводятся вручную.

> Генерация же сразу в файл подходит с качественно иной стороны -- со стороны структуры документа и его содержимого(<h1>заголовок</h1>).

Всё зависит от кривизны рук разработчика. Не надо выводить "абсолютных истин".

>> Кривость в ненужном усложнении.

> Усложнении чего? Только не надо говорить, что ОО не нужен :)

Для автоматической генерации опенофисных файлов -- не нужен. А то получим вскоре, что международный формат документов будет открываться только опенофисом(вспоминаем IE-only сайты).

>> Формат опенофисных файлов: зазипованный набор xml-ек.

> %ля, ну не надо считать меня идиотом! То, что там XML ещё не значит, что его так просто генерить. Попробуйте на досуге.

Поковырял ".ods". Таблицу по отдельныя ячейкам заполню сходу.

>> Кроме того, опенофису вполне можно скормить html, csv и т.д. Так что не вижу проблем с форматом.

> Хрен редьки не слаще, если нужны шаблоны, которые заполняются автоматически и доводятся вручную.

cat template.html | sed "s/HEADER/$header/g" -- чем не автозаполнение шаблона?

>> Генерация же сразу в файл подходит с качественно иной стороны -- со стороны структуры документа и его содержимого(<h1>заголовок</h1>).

> Всё зависит от кривизны рук разработчика. Не надо выводить "абсолютных истин".

Я не выводил истин. Я рассмотрел два качественно разных подхода(из которых структурный мне ближе).

PS. Где топикстартер?

> Для автоматической генерации опенофисных файлов -- не нужен. А то получим вскоре, что международный формат документов будет открываться только опенофисом(вспоминаем IE-only сайты).

А какой из форматов поддерживаемых ОО - международный стандарт? И таки это зависит от разработчиков. Так что не аргумент.

> Поковырял ".ods". Таблицу по отдельныя ячейкам заполню сходу.

Заполнить данными, наложить формат, разбить по страницам с вставкой прмежуточных итогов на странице (правильно получается только используя "превью") и т.д. - тоже "сходу"?

> cat template.html | sed "s/HEADER/$header/g" -- чем не автозаполнение шаблона?

Повторяю в N-ный раз - документ после заполнения часто надо вручную слегка откорректировать (секретарю) - дадим html ковырять? И см. пред. пункт.

> Я не выводил истин. Я рассмотрел два качественно разных подхода(из которых структурный мне ближе).

Только структурный подход очень жёсткий, а мне нужна максимальная гибкость. Будем весь ОО переписывать?

> PS. Где топикстартер?

А он нужен? :)

COM в Линукс отсутствует.

Внешнюю автоматизацию в Линукс можно делать:
1) Mono - через OpenOffice Novell Build
http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_1...

2) Ява
http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration

Внешнюю автоматизацию в Windows можно сделать:
1) Через .Net-UNO мост (предпочтительный вариант)
http://www.i-rs.ru/article/articleview/144/1/55/
2) COM-UNO мост - Visual Basic, VBScript,...

Библиотеки работы с ODF существуют только для .Net, Mono и Java:
http://wiki.services.openoffice.org/wiki/AODL
http://wiki.services.openoffice.org/wiki/Odf4j

>А то получим вскоре, что международный формат документов будет открываться только опенофисом(вспоминаем IE-only сайты)

А это все зависит от того, насколько вменяемо сторонние разработчики будут реализовывать эту поддержку.

Вот у ОО практически полностью реализована поддержка МСО форматов. Без всяких спецификаций.

Кстати библиотеки работы с ODF на С++ не существует.
Только .Net, Mono и Java.

Выводы делайте сами.

gaa, а ты на баше автоматизацию осилишъ?

А чем лучше многочисленные байндинги, чем COM?
А на МСО еще какие системы программируются.
Тебе и не снились...

gaa, а ты с помощью sed+awk+... сможешь сгенерировать сводную таблицу со сводной диаграммой на основе параметризованного запроса?

> А какой из форматов поддерживаемых ОО - международный стандарт?

ODF. 1 мая 2006 года принят как международный стандарт ISO/IEC 26300.

>> Поковырял ".ods". Таблицу по отдельныя ячейкам заполню сходу.

> Повторяю в N-ный раз - документ после заполнения часто надо вручную слегка откорректировать (секретарю) - дадим html ковырять? И см. пред. пункт.

АААА. Ну тады да, привязавшись к редактированию секретарём, мы действительно теряем выбор и можем в дальнейшем только повторять его действия(т.е. подходить со стороны автоматизации в офисном пакете).

>> Я не выводил истин. Я рассмотрел два качественно разных подхода(из которых структурный мне ближе).

> Только структурный подход очень жёсткий, а мне нужна максимальная гибкость. Будем весь ОО переписывать?

Максимальная гибкость как раз будет, если генерить сразу документ. А вдруг в биндинге к выбранному Вами языку не окажется, например, позарез нужной функции image.setTransparence(0.5) ?

Что делать? Ждать, пока её сделают или локти кусать?

>> PS. Где топикстартер?

> А он нужен? :)

Мне всё же интересно, для какой цели ему понадобилось изучать автоматизацию в ооо.

gaa, спроси это вот здесь:

http://community.i-rs.ru/index.php?board=9.0

Да и в OO есть еще и Base. Там тоже нужно программировать.

Привет всем!!! >PS. Где топикстартер? Вотон я!!!) Автоматизацию я использовал для своей прожки в винде, которая позволяет пользователю выбирать заголовок и формировать весь текст по шоблону для нужд руководства (офис 2003, использовал OLE ).Чтоб начальству меньше работать с офисом. Попросили написать чтоб готовое было, только фамилию вписывать). Но вот встал интересный вопрос как можно тоже самое в Linux зделать.

Я рекомендую тебе все-таки либо Моно либо Ява.

Ссылки вверху.

А цена переписывания будет очень высокой.
Дешевле Windows+OpenOffice.

Там через COM/.Net - UNO мост все просто делается.

ПС. gaa не слушай. Он кроме баша ничего не видел.

> Автоматизацию я использовал для своей прожки в винде, которая позволяет пользователю выбирать заголовок и формировать весь текст по шоблону для нужд руководства (офис 2003, использовал OLE ).

Ну вот будешь знать теперь, что такое "vendor lock-in" на примере своей программы. Однажды залочившись на микрософтские "технологии", перелезать на другое будет очень тяжело.

PS. Кстати, проблем с "подходом со стороны структуры"(см. выше по треду) я в подобном описании не вижу, так что советую попробовать, если есть достаточно времени.

> Ну тады да, привязавшись к редактированию секретарём...

...оставляя себе такую возможность...

> ..., мы действительно теряем выбор и можем в дальнейшем только повторять его действия

...мы можем использовать всю мощь офисного пакета, а не переписывать часть его функциональности заново, при этом имеем возможность ручной доводки.

> (т.е. подходить со стороны автоматизации в офисном пакете).

что, ИМХО, вполне разумно, ибо эта _фунциональность_ уже написана и отлажена, а так придётся изобретать велосипед и ездить по граблям

> Максимальная гибкость как раз будет, если генерить сразу документ. А вдруг в биндинге к выбранному Вами языку не окажется, например, позарез нужной функции image.setTransparence(0.5) ?

"Максимальная гибкость" в использовании _всей_ функциональности _прямо сейчас_, а не когда мы её напишем. На счёт отсутствия чего-то там - когда столкнусь, тогда и поговрим ;)

> "Максимальная гибкость" в использовании _всей_ функциональности _прямо сейчас_, а не когда мы её напишем.

Убедили. Исколючение оставляю только на случай недоделанного биндинга.

> На счёт отсутствия чего-то там - когда столкнусь, тогда и поговрим ;)

Тогда будет уже поздно :)