Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Вот зря Вы отказались от XML и от XSLT в частности. И Word и Excel умеют сохранять/читать данные в своем XML формате. Попробуйте файл с полями «Сохранить как» -> Тип файла: «XML-Документ Word2003» и посмотрите внутрь файла, там не так все страшно.
Вполне возможно, вы правы, но решение впервые было апробировано более 10 лет назад — с Office 97, когда с XML-файлами и их обработкой в MS Office было все весьма трудно.
Да и сейчас на многих рабочих местах в провинции, есть примеры использования Office 97.
Да и сейчас на многих рабочих местах в провинции, есть примеры использования Office 97.
А мы давно уже делаем чуть по-другому — бланки хранятся в oracle таблице на SQL сервере. Заполняет их модуль на pl-sql developer. На выходе Oracle отдает готовый сверстанный rtf — файл.
Для чего это надо? Да потому что непонятно что стоит у пользователей — от встроенного microsoft edit до OpenOffice, но RTF все читает. И удобно править отчеты, не меняя программы пользователей.
Для чего это надо? Да потому что непонятно что стоит у пользователей — от встроенного microsoft edit до OpenOffice, но RTF все читает. И удобно править отчеты, не меняя программы пользователей.
С вашим доводом о большей универсальности rtf-файла, чем, скажем, XML, как предложил один из комментаторов — согласен, когда у некоторых пользователей стоит до сих пор Office 95, понятия не имеющий про XML — приходится задумываться о поддержке старых офисных пакетов.
Что касается хранения rtf-бланков в таблице Oracle, решение интересное, и также нами используется, правда, не для хранения rtf-бланков, а для хранения простых текстовых бланков с формулами для расчета, если имеете отношение к банковским делам, — для сложных многостраничных отчетов с нерегулярной структурой, типа Приложения 9 к Положению 302-П
Для хранения rtf-файлов все же посчитали более простым отдать их на откуп пользователям — они их сами разрабатывают, обмениваются по почте и т.д. Программист разрабатывает только скрипт извлечения данных, а пользователь указывает в параметре скрипта, в какой бланк эти данные вставлять.
Что касается хранения rtf-бланков в таблице Oracle, решение интересное, и также нами используется, правда, не для хранения rtf-бланков, а для хранения простых текстовых бланков с формулами для расчета, если имеете отношение к банковским делам, — для сложных многостраничных отчетов с нерегулярной структурой, типа Приложения 9 к Положению 302-П
Для хранения rtf-файлов все же посчитали более простым отдать их на откуп пользователям — они их сами разрабатывают, обмениваются по почте и т.д. Программист разрабатывает только скрипт извлечения данных, а пользователь указывает в параметре скрипта, в какой бланк эти данные вставлять.
И еще вопрос — а какой из текстовых редакторов (Open Office, или версия MSOffice или еще что) генерит самые маленькие и читабельные rtf-файлы?
Интересует с точки зрения автоматического создания читабельного кода RTF-шаблонов.
Интересует с точки зрения автоматического создания читабельного кода RTF-шаблонов.
К сожалению, специальных исследований по минимизации размера rtf-файлов не делали. Из опыта с разными версиями
Open Office, MS Office получилось, что наименьший размер файла получается при генерации бланка в Office — чем меньше версия, тем лучше. Если делать rtf в Open Offiсe — возникают проблемы совместимости (стилевое оформление плывет) при печати их через MS Office.
Open Office, MS Office получилось, что наименьший размер файла получается при генерации бланка в Office — чем меньше версия, тем лучше. Если делать rtf в Open Offiсe — возникают проблемы совместимости (стилевое оформление плывет) при печати их через MS Office.
А у вас не было случаев, когда Word при сохранении rtf-шаблонов разбивал определение поля на несколько? У меня, к примеру, частенько было вот такое безобразие в сохранённом файле:
Здесь видно, что подставляемое поле $contract_date было разбито на 4 части: $, contract, _ и date.
Чтобы это исправить, нужно удалить лишние группы (rtf-группы — это все, что внутри фигурных скобок), и оставить только одну группу с полным текстом переменной:
В итоге я написал программу, которая парсит RTF-файлы и вносит вот такие вот исправления. Прогоняю после каждого изменения шаблона.
(Правда, в моём случае был не QUOTE, а FORMFIELD, но, думаю, это не суть важно).
{\fldrslt {\rtlch\fcs1 \af0\afs24 \ltrch\fcs0 \f0\lang1024\langfe1024\noproof\insrsid6494982\charrsid5374675 $}{\rtlch\fcs1 \af0\afs24 \ltrch\fcs0 \f0\lang1024\langfe1024\noproof\langnp1033\insrsid6494982 contract}{\rtlch\fcs1 \af0\afs24 \ltrch\fcs0 \f0\lang1024\langfe1024\noproof\insrsid6494982\charrsid5374675 _}{\rtlch\fcs1 \af0\afs24 \ltrch\fcs0
\f0\lang1024\langfe1024\noproof\langnp1033\insrsid6494982 date}}}Здесь видно, что подставляемое поле $contract_date было разбито на 4 части: $, contract, _ и date.
Чтобы это исправить, нужно удалить лишние группы (rtf-группы — это все, что внутри фигурных скобок), и оставить только одну группу с полным текстом переменной:
{\fldrslt {\rtlch\fcs1 \af0\afs24 \ltrch\fcs0
\f0\lang1024\langfe1024\noproof\langnp1033\insrsid6494982 $contract_date}}}В итоге я написал программу, которая парсит RTF-файлы и вносит вот такие вот исправления. Прогоняю после каждого изменения шаблона.
(Правда, в моём случае был не QUOTE, а FORMFIELD, но, думаю, это не суть важно).
А пользователи не хотели большего, чем просто подставлять значения в метки? В частности: показывать табличные данные с переменным количеством строк, динамически добавлять новые колонки в таблицу, разбивать/объединять ячейки в таблицах в зависимости от условий, показывать или скрывать параграфы в зависимости от условий, ну и много всего остального «динамического».
Со статическим шаблоном и простой подстановкой значений в метки далеко не уедешь, для более-менее серьезной системы нужно уметь изменять шаблон программно.
Со статическим шаблоном и простой подстановкой значений в метки далеко не уедешь, для более-менее серьезной системы нужно уметь изменять шаблон программно.
Показ табличных данных с переменным количеством строк реализован добавлением таблицы в rtf-файле (в бланке вводится заголовок и первая строка таблицы с названиями переменных, а скрипт автоматически копирует первую строку нужное количество раз), но решение не очень красивое — необходимо соглашение с программистом о том, где и как расположена таблица в rtf-файле.
Динамическое добавление новых колонок, объединение/разъединение ячеек — в практике не так уж требуется. Область применения описанных в топике скриптов в банковской работе — кредитные договора, договора вкладов, договора залога и т.д. — там таких сложных изменений представления «на лету», т.е. под управлением потока данных редко требуется. Для таких случаев предполагается разрабатывать отдельные бланки.
Опыт показал, что пользователю удобнее сделать самостоятельно новый бланк, не привлекая программиста чтобы включить условия в уже используемый.
Динамическое добавление новых колонок, объединение/разъединение ячеек — в практике не так уж требуется. Область применения описанных в топике скриптов в банковской работе — кредитные договора, договора вкладов, договора залога и т.д. — там таких сложных изменений представления «на лету», т.е. под управлением потока данных редко требуется. Для таких случаев предполагается разрабатывать отдельные бланки.
Опыт показал, что пользователю удобнее сделать самостоятельно новый бланк, не привлекая программиста чтобы включить условия в уже используемый.
Костыль. Плохой. Сейчас докажу.
Пользователь принципиально не должен «дизайнить» шаблон отчёта.
Пользователь должен посылать желаемый вид шаблона директору, тот утверждать и спускать программисту (если контора большая, то через начальника IT). А программист — разрабатывать и отлаживать.
и после пятой переделки уже существующего отчёта директор должен позвонитькому-то типа НачФинОтдела и сказать типа: «вы там не о__ели новые формы отчётиков рисовать! Может уже делом займётесь!?»
Пользователь принципиально не должен «дизайнить» шаблон отчёта.
Пользователь должен посылать желаемый вид шаблона директору, тот утверждать и спускать программисту (если контора большая, то через начальника IT). А программист — разрабатывать и отлаживать.
и после пятой переделки уже существующего отчёта директор должен позвонитькому-то типа НачФинОтдела и сказать типа: «вы там не о__ели новые формы отчётиков рисовать! Может уже делом займётесь!?»
Так и происходит в реальности, просто детали процесса были опущены, чтобы не загромождать изложение. Пользователь (сотрудник отдела, разрабатывающего кредитные договора) правит шаблон отчета, или дизайнит новый (на основе старого, например) и посылает начальнику. Начальник утверждает и выкладывает в каталог шаблонов, который автоматически рассылается по всем продажным подразделениям.
Цель — замкнуть эту цепочку внутри бизнес-подразделений, не привлекая программистов и службу поддержки.
Программист требуется, когда надо внести в скрипт извлечения данных для расстановки в шаблон каких-то новых переменных, таблиц и т.д.
Служба поддержки выполняет заявки по предоставлению права утверждать шаблоны в качестве базовых и рассылать их по подразделениям.
Цель — замкнуть эту цепочку внутри бизнес-подразделений, не привлекая программистов и службу поддержки.
Программист требуется, когда надо внести в скрипт извлечения данных для расстановки в шаблон каких-то новых переменных, таблиц и т.д.
Служба поддержки выполняет заявки по предоставлению права утверждать шаблоны в качестве базовых и рассылать их по подразделениям.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой способ подготовки отчетов на основе rtf-бланков