7. Выбор технологии для реализации проекта

В результате сравнительного анализа был сделан выбор в пользу использовании Javaпо следующим причинам:

• Самый используемый язык программирования уже на протяжении шести лет (если говорить и постоянном лидерстве).

• Независимость от архитектуры. Разработчик может полностью сконцентрироваться на написании функционала. Нет необходимости задумываться о том, как обеспечить работу программы на разных платформах. Это позволяет больше времени уделять функционалу, что введёт к улучшения качества написанных программ.

• Не требует дополнительного программного обеспечения для выполнения. Единственным требованием является только наличие установленной Java-машины. Это является существенным плюсом, так, например, С# требует .NETи поэтому только может работать под операционными системами семействаMicrosoft.

• Большое сообщество разработчиков.

• Большее число библиотек для работы с документами, но об этом чуть ниже.

Так как разрабатываемый проект должен обеспечить заполнение договоров, то очень важным моментом была возможность работы с Word. Тут самым лучшим вариантом было бы использование С#, так как этот язык программированияMicrosoftпредоставляет такие же возможности для работы сMicrosoftOffice, как иVBA. Но так как он работает только подWindowsи требует для своей работы дополнительное программное обеспечение, и я с ним совершенно не знаком, тоC# был отброшен. Затем, проанализировав имеющиеся библиотеки для работы сWord, был сделан выбор использоватьJava, так как для этого языка написано больше библиотек, чем дляPHP.

3. Разработка проекта

   1. Разработка плана решения поставленной задачи

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

Первоначально к разрабатываемому проекту были предъявлены следующие требования:

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

• Выходные документы должны быть совместимы с Word2000,XP, 2003.

• Разрабатываемая система должна в максимальной степени исключать участие человека.

Больше, первоначально, никаких требование не стояло, но они появились в процессе разработки.

На самом начальном этапе разработки самым сложным моментом всего разрабатываемого проекта казалось организовать взаимодействие между выбранным языком программирования и MicrosoftWord. Со временем стало ясно, что первые впечатления оказались верными и организация взаимодействия действительно является самым сложным моментом всего проекта. Поэтому я считаю необходимым остановиться на данном моменте поподробнее.

В результате продолжительного поиска в сети Internetя пришёл к выводу, что на данный момент, к сожалению, существует весьма незначительное число библиотек для работы с документамиMicrosoftWord. На мой взгляд, данную ситуацию можно объяснить тем, чтоMicrosoftWordработает только на нескольких семействах операционных систем:Windows,Mac, в отличии отJava, которая также работает на большинстве, если не на всех более-менее современных операционных системах. ТакжеMicrosoftWordявляется достаточно дорогим и закрытым, в плане документации для разработчиков, приложением, что является второй причиной столь низкого числа библиотек для работы сMicrosoftWord.

Неудивительно, что наибольший функционал из найденных библиотек предоставляли несколько платных библиотек, самая «доступная» из которых стоит от 850 американских долларов. И это только самая «простая» версия. Поэтому все платные библиотеки были сразу отброшены.

Из бесплатных библиотек я, в первую очередь, обратил внимание на библиотеку ApachePOI, которая присутствует на рынке уже на протяжении нескольких лет и имеет широкие возможности для работы сWordиExcel. В том числе возможности для работы с .docxи .xlsx. Стоит отметить, что в процессе разработки данной библиотеки, разработчики делали главный упор на работу с электронными таблицамиExcel. Так как именно данный продукт из пакетаMicrosoftOfficeпользуется наибольшей популярностью среди пользователей. В то время как поддержкаWordпоявилась только в нескольких последних версиях. И ещё не обладает теми же возможностями, что дляExcel. Поэтому не удивительно, что во время использования данной библиотеки была обнаружена следующая проблема:POIплохо работает с таблицами в .docфайлах. Так, при редактировании документа, который содержит таблицу более чем с девятью столбцами, файл становиться не читаемым. Этот недостаток заставил отказаться от использованияApachePOI, так как некоторые файлы, с которыми будет осуществляться работа, содержат таблицы, по крайней мере, с тринадцатью столбцами.

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

Simple API for XMLспособ последовательного чтения/записиXML-файлов. Обычно SAX-парсерытребуют фиксированного количества памяти для своей работы, но не позволяют изменять содержимое документа. Всё, что делает SAX-парсер, это сообщает вызвавшему приложению о встреченных распознанных элементах XML-разметки или о встреченных ошибках. Связь парсера с вызывающим приложением, как правило, осуществляется посредствомфункций обратного вызова.

SAX был разработан членами почтовой рассылки XML-DEV, а его Java-версия является сейчас проектом SourceForge (см.Ресурсы). Целью проекта было обеспечение более естественного средства для работы с XML - другими словами, такого, которое не включает в себя таких расходов и концептуальных сложностей, каких требует DOM.

Результатом был API, который является событийно-базированным. Парсер посылает события, такие, как начало и окончание элемента, в обработчик событий, который обрабатывает информацию. Затем с данными имеет дело само приложение. Исходный документ остается без изменений, но SAX обеспечивает средства для манипулирования данными, которые затем могут быть направлены в другой процесс или документ.

Но из-за требования сохранить совместимость с Word2000,XPэта идея была также забракована. Так как эти версииWordоткрывали такой файл, как простойXMLи не могли преобразовать его в требуемый вид. Из-за того, что возможность сохранять файлы в виде шаблонаXMLпоявилась только в пакетеMicrosoftOffice2003.

Оставался только один вариант, который приходил на ум: использование .rtfв качестве формата входных и выходных шаблонов. Это позволяло сразу же решить проблему совместимости, из-за которой был забракован вариант сXML. Ведь .rtfподдерживает большинством, если не всеми текстовыми редакторами. Например, тем жеWordPad, который поставляется вместе с операционной системойWindows.

Поиск сторонних библиотек для работы с .rtfне привёл к успехам. Так как большинство этих решений предназначались только для создания документов. Например,IText,JasperReportsглавное назначение которых заключается в создании отчёта на основании какой-то информации. Но они не содержат методов для чтения уже существующих документов. Поэтому пришлось от них отказаться, так как создавать каждый раз выходной файл в ручную очень накладно, как для программиста, так и для сервера. К тому же, если договор измениться, то придётся менять и его создание в программе. Другие же библиотеки, которые позволяли осуществлять редактирование уже имеющихся файлов, были либо платные, либо не поддерживали работу с русским языком.

Поэтому было решено разработать собственное решение, используя встроенные в Javaвозможности. Поиск вJava-документации показал, чтоJavaимеет скромные возможности для работы с файлами в формате .rtf. Но оказалось, что даже этих скромных возможностей хватает для решения поставленной задачи.

Правда, стоит отметить тот факт, что из-за того, что операционные системы семейства Windowsимеют встроенный текстовый редакторWordPad, то пришлось отказаться от идею реализовать в разрабатываемой системе, возможность печати документа без передачи его пользователю. Это вызвано тем, что браузеры, при попытке вывести заполненный документ в браузер, распознают формат .rtfи передают заполненный файл вWordPad. Но так какWordPadесть на каждом компьютере, где установлена операционная системаWindows, то печать заполненного документа не представляет собой никакой проблемы.

Единственным минусом такого решения являлось то, что строковый поиск в Javaне работает, если в качестве искомой комбинации указаны русские буквы. Поэтому в исходном шаблоне было решено, в качестве заменяемых значений использовать слова, написанные латиницей. В результате встала необходимость в исходных шаблонах вставить эти «искомые» слова. Оставлять это на «совести» человека, который составляет договоры, казалось не лучшей идеей. Так как это сразу снижала ценность создаваемого проекта: возрастает нагрузка на этого человека. Кроме того, что это обременяет «составителя», который, вряд ли, захочет этим заниматься, Это увеличивает вероятность ошибки: «составитель» может вставить слово не в то место, либо вставить неправильное слово. Поэтому было принято решение автоматизировать этот процесс при помощи использованияVBA.

VBAпозволяет создать макрос, который возьмёт на себя весь процесс вставки требуемых слов в требуемое место. Что и было сделано. Создание макроса также позволило решить проблему с выравниванием текста в выходных файлах. Так как .rtfдостаточно специфичен, и не имеет какого-то конкретного символа перевода строки, то невозможно выполнить выравнивание текста до нужной позиции без использование вспомогательных элементов. Поэтому в макрос была добавлена функциональность, которая подсчитывает, какое число пробелов отводиться для каждого поля, и записывает его в текстовый файл. Который в свою очередь считываетсяJavaвместе с входных шаблоном. Затем программа анализирует введённый в форму пользователем текст, определяет длину данного текста в пробелах и прибавляет недостающее количество пробелов к пользовательскому тексту, что позволяет обеспечить требуемое выравнивание в выходных файлах, что в свою очередь освобождает пользователя от ручного выравнивания.

Время выполнения макроса зависит от вида договора и производительности компьютера, на котором данный макрос запущен. Так, у меня, создание шаблона для самого сложного договора заняло порядка 25 секунд., что гораздо быстрее «ручного» процесса, а что более важно – более правильное.

Также стоял вопрос, организовывать ли динамическое создание шаблона и формы для заполнения. К плюсам такого создания можно только отнести простоту в сопровождении проекта, так как нет необходимости при, скажем, добавлении или удалении поля, изменять форму. Так как форма создаётся каждый раз заново. Но минусов у такого подхода оказалось значительно больше. Главный из них это увеличение нагрузки на сервер: по каждому вызову считывать файл, создавать шаблон, затем генерировать форму. Также это привёло бы к ухудшению функциональности и увеличению числа ошибок при заполнении договора. Поэтому было решено отказаться от данного решения.