ПРИНЦИПЫ ФОРМИРОВАНИЯ ТЕКСТОВЫХ ДОКУМЕНТОВ НА ОСНОВЕ ШАБЛОНОВ ИСПОЛЬЗУЯ FILEMAKERПерла АркадийТриАПринт

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

Мы будем рассматривать эту задачу на примере формирования текста договоров.

Форматы файлов которые мы будем получать: PDF, RTF, DOCX.

.PDF

.RTF

.DOCX

Старый формат .DOC считается устарвешим и неудобным

Основной принцип при формировании документа – использование шаблона, с последующей заменой ключевых слов в шаблоне на текст из базы данных FileMaker

Лайот для редактирования данных документа

Шаблон документа Полученный документ

Вариант PDF

Пример формирования многостраничного договора на основе двуязычного шаблона с подстановкой всех необходимых

реквизитов на основе одного из реализованных проектов …

Пользователю, в действительности, не всегда нужен именно редактируемый текстовый файл, а нужен способ корректно сформровать документа, подставив туда все необходимые данные из базы. А финальный файл документа может быть и не редактируемым. Часто это даже лучше, так как страхует, от случайной правки и «поехавшего» форматирования, в случае использования разных версий редакторов.

Лирическое отступление:

В настройках проекта формируются шаблоны документов.

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

Пользователь в необходимых местах проставляет ключевые слова, которые будут заменены реальными данными при формировании документа

Карточка договора

Пользователь заносит основные данные о договоре и формирует договор выбирая шаблон из списка.

При необходимости он может внести корректировки в текст договора, добавить новые или удалить ненужные пункты (шаблон при это не затрагивается).

Когда все готово, осталось только открыть печатную форму договора, распечатать или сохранить как pdf…

Лаойт печтаной формы выводится в режиме списка и основан на таблице пунктов договора.

Размер поля (и body) сделан очень большим «с запасом», чтобы даже достаточно длинные тексты пунктов договора умещались. При этом настроены свойства Sliding up для схлопования пунктов.

Двуязачность реализована с помощью репетишен полей

Таблица contracts_row (пункты договора) содержит калькулируемое поле text_calc которое подставляет в текст пункта договора соотвествующиз значения вместо ключевых слов, используя функцию Subsitute

В показанном примере пользователь может меняь местами покпателя и поставщика поэтому в калькуляции присутствует if

Варинты экспорта в RTF и DOCX рассматриваются на оснвое специального подготовленного файла примера

CreateDocsSample.fmp12

Из добавленых шаблонов выбираем нужный и нажимаем сформировать

Полученный документ появляется в конейнере

Шаблон документа с ключевыми словами

Полученный документ с подставленными данными

Экспортируем файл шаблона

на диск из контейнера

Читаем текст документа

Заменяем в тексте

ключевые слова из базы

данных

Записываем текст обратно в

файл

Импортируем новый файл в базу данных

Основной принцип формирования документа из шаблона

Процесс извелечения текста из файла шалона и записи обратно зависит от формата файла.

Собственно, в этом заключается наша главная задача…

«Внутри» RTF это текстовый файл, где сам текст документа перемежается управляющими коммандами. Используемые нами ключевые слова в нем легко находятся.

Основная проблема c RTF, что русский текст (и любой, кроме английского) передается в RTF в виде последовательности UNICODE кодов, снабженных специальными резделителями: \u перед кодом идва пробела после.

Нам нужна специальная custom-функция для перекодировки текста.

Let ([Symbol = Left ( text ; 1 );kod = Code ( Symbol )];

// если код символа больше 127 то преобразуем иначе оставляем как есть (англ буквы и стандартные символы)

If ( kod > 127; "\u" & kod & " " ; Symbol )& If ( Length ( text ) > 1; text_to_RTF ( Right ( text ; Length ( text )-1 ) ); "")

)

Для работы с файлами на чтение и запись используем бесплатный плагин BaseElement (http://www.goya.com.au/baseelements/plugin )

При работе BaseElement использует формат пути к файлу отличный от принятого в FileMaker. Формат пути также отличатется в зависимости от платформы (mac или win) поэтому для пути файлов мы используем отдельные переменные постфиксом BE

Теперь попробуем зайти в джунгли формата word – docx…

DOCX – это сжатая zip папка содержащая несколько подпапок и файлов

В этом мы можем легко убедится переименовав любой docx файл в zip и распоковав его

Количество файлов в папке может отличаться, но нас всегда интересует файл document.xml - он содержит основной текст документа.

Колонтитутулы и футеры хранятся в отдельных файлах. Их может быть несколько в зависимости от их количества в документе.Например: header1.xmlheader2.xmlfooter1.xmlfooter2.xmlи т.п.

Пример document.xml

Не пугаемся, мы можем работать с ним как с обычным текстом заменяя ключевые слова

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

Вторая часть скрипта. Замещаем ключевые слова данными, записываем файлы обратно, zip-ем папку, как docx файл и помещаем его в контейнер.

Особенность работы функции BE_Zip плагина BaseElement не позволяет корректно упаковать zip файл в windows, чтобы он нормально открывался в word (получается направильная структура архива).

Поэтому для win мы используем архиватор коммандной строки 7za.

Ключевые слова не обязательно жестко прописывать в срипте. В CreateDocsSample ключевые слова прописываются специальное поле с репетишен template_keywords, подставляемые значения в поле template_field_name. На основе этих полей формируется поля-калькуляуции template_formulas (для docx) и template_formulas_rtf (для rtf)

Значения параметров для функции Substitute замены формируется на осове функции List (template_formulas). Полученное выражение вычисляется с помощью EvaluateТаким образом мы получаем возможность замены и добавления ключевых слов и их значений без редактирования скрипта обработки. Мы можем указать не только наименования полей, но любые функции FM

В реальных проектах рекомендуется вместо репетишен использовать отдельную таблицу ключевых слов

Спасибо за внимание!

Вопросы?