WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 11 |

В качестве структуры документов был выбран тип документов DTD DocBook/XML[6], разработанный для создания документации. В данной схеме семантическая разметка создаётся в DocBook/XML, а преобразование информации в различные форматы выполняется с помощью XSL-стилей[5]. Собственно, XSL-стили и определяют внешний вид информации.

Для DTD DocBook/XML существуют XSL-стили, которые позволяют получать из одного и того же исходного документа выходные форматы для печатных публикаций (PDF и PS), online-публикаций (XHTML/HTML одним файлом или разбитым на много файлов), справочных систем (man pages, Eclipse Help, Java Help, HTML Help).

Модульная разработка документов При написании документации часто встречается ситуация, когда разные фрагменты документа пишут разные авторы. При создании документации из модульных фрагментов нужно иметь возможность объединять документы и их сопутствующие файлы (например, файлы с изображениями). При этом каждый фрагмент автор пишет как самостоятельный документ в произвольной кодировке.

Для объединения документов можно использовать спецификацию XInclude[3] (которая пока находится в стадии рекомендации, однако уже поддерживается многими программными средствами. При этом в результирующем документе нужно обеспечить уникальность идентификаторов тегов (id) и уникальность имён файлов с изображениями (images) из разных фрагментов. Такой уникальности можно достичь либо специальным преобразованием id/images, либо соблюдением общего соглашения об именовании id/images.

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

Для всех этих задач в ALT Linux Documentation Project разработан набор стилей, доступный по адресуhttp://docs.altlinux.ru/ releases/xsl/current/common/ Средства для создания и публикации документов Для создания документов в формате DocBook/XML можно использовать как обычный текстовый редактор, так и специализированные редакторы — emacs, vim, conglomerate1, tkxmlive2. Документы можно создавать в любой кодировке (которую поддерживает XML-парсер), правильно указанной в объявлении XML.

Для обработки и преобразования документов в проекте ALT Docs используются библиотеки и утилиты libxml2/libxslt[7]. Несмотря на название — парсер и инструментарий для Gnome — это независимый от Gnome[8] кроссплатформенный набор инструментов, написанный на C, компактный, быстрый и не требующий дополнительной установки Java.

Парсер libxml2 поддерживает большинство спецификаций семейства XML, в том числе XML Inclusions 1.0[3], XPath 1.0[4], а также многие расширения EXSLT[9], что позволяет максимально использовать возможности стилей DocBook XSL.

Для выполнения всех этапов сборки можно использовать Gnu Make http://www.gnu.org/software/make/.

Список литературы [1] ALT Linux Documentation Projecthttp://docs.altlinux.ru [2] Extensible Markup Language (XML) 1.http://www.w3.org/TR/REC-xml/ [3] XML Inclusions (XInclude) Version 1.http://www.w3.org/TR/xinclude/ [4] XML Path Language (XPath)http://www.w3.org/TR/xpath [5] The Extensible Stylesheet Language Family (XSL) http://www.w3.org/Style/XSL/ [6] DocBook DTDhttp://docbook.org [7] The XML C parser and toolkit of Gnomehttp://xmlsoft.org/ [8] GNOME: The Free Software Desktop Project http://www.gnome.org/ http://www.conglomerate.org http://tkxmlive.sourceforge.net [9] EXSLT is a community initiative to provide extensions to XSLT http://www.exslt.org/ [10] FOP (Formatting Objects Processor) http://xml.apache.org/fop/index.html 13:30–13:Алексей Крюков Москва, МГУ им. М.В. Ломоносова, Исторический факультет Проект: СОЛУНЬ http://www.thessalonica.org.ru Разработка расширений для OOo Writer на примере проекта СОЛУНЬ Аннотация:

В докладе рассматривается процесс переноса отработанных решений с платформы MS Word на OpenOffice.org, а также сравнительные достоинства используемых для этой цели средств разработки (Basic, Python, Java). Основное внимание уделяется программированию поиска/замены и ввода различных национальных символов в текстовых документах. Попутно предполагается обратить внимание на основные подводные камни, ждущие разработчика на этом пути.

Проект СОЛУНЬ (в латинском написании — Thessalonica), которому посвящено настоящее сообщение, сам по себе имеет узкоспециальное назначение, будучи предназначен для облегчения жизни филологовклассиков и историков-эллинистов. Тем не менее, представляется, что знакомство с его историей (достаточно сказать, что версия этой программы для OpenOffice.org прошла в своём развитии три этапа, будучи последовательно переписана на Basic, Python и Java) способно предохранить от большого количества синяков и шишек многих разработчиков расширений для OpenOffice.org.

СОЛУНЬ начала своё существование в виде макропакета для Microsoft Word 97 и выше, предназначенного для решения двух ключевых проблем, с которыми ежедневно сталкивается любой специалист, чья работа связана с классическим греческим языком. Во-первых, отсутствие общепринятой 8-битной кодовой страницы, которая покрывала бы акцентированные греческие символы, породило множество используемых для этой цели несовместимых друг с другом кодировок. Соответственно, становится актуальной задача преобразования текста из этих кодировок в Юникод и обратно. Во-вторых, необходимо обеспечить возможность доступа ко всему множеству акцентированных символов с клавиатуры.

Познакомившись с OpenOffice.org, я должен был прежде всего ответить для себя на вопрос, предоставляет ли он необходимые возможности для реализации аналогичных функций. Поначалу мне казалось, что реализация конвертера во всяком случае не должна вызывать затруднений: ведь для этого требуется лишь возможность многократного поиска и замены фрагментов текста с нужным форматированием. В то же время я не видел возможности обеспечить ввод акцентированных символов внутренними средствами OpenOffice.org, так как настраиваемость клавиатуры в нем ограничена и заведомо не идёт ни в какое сравнение с уникально богатыми в этом отношении возможностями MS Word. Практическая работа над проектом показала ошибочность обоих этих предположений.

Точно так же не оправдалась надежда малой кровью перевести готовые макросы с VBA на StarBasic. Главная проблема заключалась даже не в различии объектной модели, а прежде всего в том, что разработку проекта пришлось начать с реализации ряда чисто технических функций. Например, пытаясь обеспечить сохранение настроек, я столкнулся с тем фактом, что API OpenOffice.org предоставляет лишь низкоуровневый интерфейс для доступа к реестру приложения. Соответственно, потребовалось затратить определённые усилия на создание модуля, который предоставлял бы некий набор функций, сходных с привычными по WordBasic getPrivateProfileString/setPrivateProfileString. Аналогичным образом дело обстояло с доступом к элементам диалоговых окон.

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

Лишь завершив этот предварительный этап работы, я смог перейти к к программированию алгоритма поиска и замены символов, и тут меня постигло жестокое разочарование: оказалось, что поиск форматированного текста в OpenOffice.org работает некорректно, и полагаться на него нельзя1. Наиболее естественным обходным путём был поиск фрагментов текста без указания форматирования с последующей его проверкой, но и этот вариант оказался чреват непредсказуемыми последствиями. Лишь после выхода стабильной версии OpenOffice.org 1.удалось найти приемлемое решение, состоявшее в отказе от множества последовательных операций поиска: теперь поиск выполняется единственный раз, с длинным регулярным выражением в качестве аргумента. Зато оказалось, что API OpenOffice.org предоставляет возможность перехватывать клавиатурные нажатия, адресованные активному окну, в результате чего удалось реализовать менеджер раскладок клавиатуры, обладающий даже большими возможностями, нежели соответствующая часть макропакета для MS Word.

По мере разрастания проекта становилось всё очевиднее, что большинство его модулей выглядело бы намного изящнее, будучи реализовано в качестве объектов. Увы, такая возможность недоступна в StarBasic (в отличие от MS VBA!). Собственно, в этом заключалась главная причина, заставившая меня обратиться к Python, а затем и к Java. Моё первоначальное предпочтение Python было обусловлено следующими двумя обстоятельствами. Во-первых, Python сходен с Basic в том отношении, что оба эти языка позволяют напрямую обращаться к свойствам и методам каждого объекта UNO, в то время как в Java такой объект должен быть вначале представлен в качестве реализации того или иного интерфейса (это делается с помощью вызовов UnoRuntime.queryInterface()).

Вторая причина выглядит несколько неожиданной, но, в сущности, создаёт едва ли не больше затруднений: дело в том, что Makefile’ы для представленных в OpenOffice.org SDK примерных проектов на Java отнюдь не отличаются прозрачностью и, самое главное, слишком тесно привязаны к структуре каталогов самого SDK, ввиду чего извлечь оттуда полюбившийся образец оказывается не так-то просто.

Реализация компонентов OpenOffice.org на Python, безусловно, технически проще, однако она заставляет разработчика учитывать ряд ограничений. Самое главное из них заключается в том, что на данный момент практически не существует удобного способа инсталляции модулей Python, которые не представляли бы собой в то же время реализацию компонентов UNO. Именно поэтому приходится жёстко выдерживать схему один файл—один компонент, и, соответственно, регистрировать в качестве сервисов UNO даже те объекты, которые предназначены только для использования внутри данной программы. Поскольку Пользуясь случаем, хочу лишний раз привлечь внимание аудитории к заполненному мною по этому поводу issue 10569.

же сервис UNO непременно должен быть реализацией какого-либо интерфейса, приходится дополнять пакет описаниями новых интерфейсов, что создаёт дополнительные проблемы. Наконец, сама реализация шлюза Python—UNO, несмотря на все усилия её разработчика, в настоящее время содержит немало ошибок, которые могли бы служить темой отдельного сообщения. Так, лишь в OpenOffice.org 1.1.2 была исправлена проблема с компилированными библиотеками *.pyd под win32, из-за которой, естественно, едва ли не большую часть модулей из стандартной поставки Python нельзя было использовать на этой платформе. Такого рода ошибки в конечном счёте и сделали необходимым перенос кода СОЛУНИ на Java.

Таким образом, история проекта СОЛУНЬ служит лишним подтверждением того факта, что Java по-прежнему остаётся предпочтительным средством разработки расширений для OpenOffice.org. В то же время единство объектной модели UNO позволяет осуществлять перенос уже готовых проектов на другой язык без особых потерь, делая необходимые для этого затраты усилий не столь критичными, как это могло бы быть в иной ситуации.

13:00–13:Пётр Савельев Санкт-Петербург, JSC Eltel / DrWeb Практика использования формата документов OpenOffice.org для веб-публикации Аннотация:

Практика использования формата документов OpenOffice.org для вебпубликации Введение Проект посвящён использованию возможностей преобразования и публикации документов OpenOffice.org. Внутреннее представление документов OpenOffice.org определяет сравнительную лёгкость написания для них XSLT-преобразований, а также использования уже имеющегося XML для организации хранения данных в СУБД. Основной целью проекта была минимизация усилий пользователя при подготовке документа к веб-публикации. Для реализации были выбраны, помимо OpenOffice.org, Zope и PostgreSQL.

OpenOffice.org Офисный пакет, позволяющий производить оформление документа исключительно стилями, что заметно облегчает как непосредственно работу с документом, так и его преобразование. Ещё одной ключевой особенностью стало использование WEBDAV как протокола доступа к документам в сети.

Zope Система публикации документов. Благодаря архитектуре (написана на Python), позволяет легко создавать собственные модули, дополняющие или перегружающие уже существующие возможности.

PostgreSQL СУРБД, одной из ключевых особенностей которой является возможность создания хранимых процедур и функций как на SQLподобном диалекте, так и на Python, Tcl или Perl. Возможно также подключать бинарные модули (.so), написанные на С. Модуль xml (автор John Gray) был использован в качестве базы для добавления функциональности XSLT-преобразований.

Организация и развитие проекта В качестве результата работы надо проектом видится система, позволяющая сохранять документы прямо из OpenOffice.org (через WEBDAV), производящая автоматический импорт при сохранении, и автоматический экспорт в различные форматы при запросе определённых URL.

Уровень базы данных В PostgreSQL хранится XML, импортированный из документов OpenOffice.org. Предполагается импорт документа в виде одной XMLзаписи, на данный момент различные части документа (styles.xml, content.xml, meta.xml etc.) хранятся в различных таблицах.

Уровень приложений Обработка XML с помощью XSLT производится также в PostgreSQL с помощью модуля xml, с добавленным функциями XSLTпреобразования и несколько изменённой функцией выборки по XPath.

На момент написания заметки, практически вся добавленная автором функциональность в том или ином виде уже присутствовала в модуле xml2 того же John Gray.

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

Уровень представления Обработку запрошенных URL производит продукт для Zope, перегружающий возможности классов ObjectManager и SimpleItem. На данный момент, один из классов продукта, DBFS, производит отображение набора хранящихся в БД документов в виде набора URL, соответствующих ID записей в БД. Однако, в работе находится версия продукта, производящего отображение из БД от одного до k произвольных записей в одном документе. Это даст возможность комбинировать хранящиеся документы и более гибко организовывать URL доступа к ним в Zope.

Заключение На данный момент проект находится в начальной стадии развития. В результате работы должна получиться система управления документами, в качестве формата хранения использующая XML OpenOffice.org. Система должна предоставлять возможность простой публикации документов (Save as... в OpenOffice.org), возможность экспорта с помощью XSLT-преобразований (на данный момент написаны преобразования OpenOffice.org-[X]HTML), и возможность контроля версий хранящихся документов и online-поиска. Предполагается возможность экспорта, комбинирующего содержимое нескольких документов.

Это также даст возможность оформления документа уже хранящимися в БД наборами стилей.

14:15–15:00: Обеденный перерыв Вечернее заседание 15:00–17:Секция (Председатель — Алексей Новодворский) 15:00–15:Николай Гарбуз, Аскар Рахимбердиев Москва, Инфра-Ресурс Проект: OpenOffice.ru Eclipse SDK Аннотация:

Согласно результатам анонимного опроса посетителей сетевого проекта JUGA.RU, почётное третье место по популярности среди разработчиков в России занимает интегральная среда разработки Eclipse SDK. Однако, если внимательно рассмотреть результаты голосования, то Eclipse SDK используют только 12 разработчиков из 100. Первое и второе место по популярности, а также основную долю на рынке делят две другие замечательные среды разработки: Borland Jbuilder (28Авторы ставят перед собой задачу разобраться, почему разработчики выбирают средства, которые дороже Eclipse SDK более чем в (!!!) раз. Настоящая работа посвящена исследованию выявленного парадокса через изучение истории, философии, архитектуры платформы Eclipse SDK, а также сравнительного анализа особенностей и отличий на примерах реальных проектов.

Не умаляя достоинств лидеров рынка (Borland Jbuilder и IntelliJ IDEA) с первого взгляда бросается главное отличие между популярными средами разработки на Java. Eclipse SDK распространяется под свободной лицензией, а точнее под лицензией EPL (Eclipse Public License), что на практике означает «бери и пользуйся бесплатно», в то время как конкуренты и лидеры опроса распространяются под патентными (Proprietary) лицензиями, что на практике выглядит так:

IntelliJIDEA $499.BorlandJbuilderX DE $1000.

Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 11 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.