Подписаться  на наше издание быстро и дешевле чем где-либо Вы можете прямо сейчас! Подписаться! 

 

 

Те, кто следит за легендарным FoxPro, отметили появление в девятой версии генератора отчетов в виде XML. Как же создавать XML-отчеты вручную?

 

Формат XML, как известно, служит для хранения и передачи данных, а также описывает документы с гибкой древовидной структурой. Но всегда ли мы используем этот формат так, как следует? В сети вы можете найти десятки инструментов DBF2XML, которые заменяют табличную структуру DBF-файлов тэгами XML. Даже сайт компании “Майкрософт” предлагает небольшой код, превращающий строки DBF в XML-записи. Посмотрите на страницу http://support.microsoft.com/default.aspx?scid=kb;EN-US;q191758, и вы поймете, о чем идет речь.


Однако является ли разумным использованием прямой перевод таблиц DBF в XML? Можно привести как минимум три серьезных возражения против такой искусственной конверсии.


Во-первых, XML очень избыточен: он дублирует имя поля в каждой строке, в то время как DBF содержит метаданные только в заголовке. В результате вы можете увеличить размер файла в три, пять и более раз. Например, поле логического типа с именем IsWorkerHasChildren будет представлено в виде < IsWorkerHasChildren >Y< /IsWorkerHasChildren >, и его размер вырастет в 44 раза!


Конечно, жесткие диски дешевеют, но файловая система будет работать совершенно по-разному с базой данных размером 10 Мб и 440 Мб. Для текстовых полей ситуация будет неоднозначной – XML может не включать пробелы, завершающие строки. Так что размер XML будет более выигрышным, если средняя длина удаленных пробелов окажется больше удвоенного размера имени поля, плюс пять знаков разделителей. Расплатой за сжатие пробелов будет переменная длина записи, что сводит на нет механизм прямого доступа, хотя он и так никогда не применялся в XML.


Также можно исследовать поле на предмет отсутствия значения и вообще удалять пустой тэг, но само понятие "отсутствие значения" для DBF-файлов является неопределенным. Также возникает проблема однозначного восстановления: возможно, нулевое значение или пустая строка не были эквивалентны NULL. Вообще, линейная зависимость размера файла данных от длины имен столбцов выглядит весьма абсурдно.


Во-вторых, XML сам по себе не поддерживает никаких содержательных типов данных, в частности пользовательских, которые можно создать в SQL на основании базовых типов. Вместо этого все значения представляются строками, что не позволяет контролировать типы естественным и автоматическим образом, а также применять оптимизацию бинарных типов. Для контроля типов приходится вводить дополнительные атрибуты, собственные или задаваемые в шаблонах Schema, с их последующей интерпретацией нестандартным и вынужденным образом. Естественно, кроме типов, вы теряете информацию о связях таблиц, ограничения уникальности и индексы.


В-третьих, методы доступа к XML не рассчитаны на быстрый поиск и линейный доступ, даже если данные являются конвертированными однотипными записями. Фактически, в XML вы вообще не имеете дело с записями. Каждый следующий фрагмент может иметь другую структуру, так что запросы, например, XPath, работают с древовидными структурами. Загоняя таблицы в XML, вы разделяете форму и содержание, обеспечивая доступ к линейно организованным данным совершенно неподходящими средствами.


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


Таким образом, можно сделать вывод, что конверсия DBF в XML не имеет под собой достаточно серьезных предпосылок.


Однако из этого не следует, что XML не может быть эффективно использован в качестве формата выходных данных. Дело в том, что никто не застрахован от превращения своих документов и отчетов в вэб-страницы, а точнее, мы все обречены на это. Так почему бы заранее не генерировать отчеты в современной и универсальной форме? В конце концов, распечатать (X)HTML или вывести его в формате PDF не сложнее, чем любой другой документ, а наоборот, удобнее, поскольку средства для просмотра и печати всегда под рукой.

 

Начинать будем сначала


Создание XML-формы или отчета начинается точно так же, как и создание обычного бумажного отчета – с листа бумаги, карандаша или ручки, а также с активного общения с потребителями: представителями бухгалтерии, отдела маркетинга или людьми от заказчика. Следующий шаг – создание макета документа с помощью одного из сотни HTML-редакторов: и вы, и заказчик должны заранее представлять, как будет выглядеть будущий документ. Если вы не сможете достичь согласия относительно необходимого дизайна и функциональности “вручную”, то вы вряд ли сделаете это программно. В конце концов, нет ничего лучше для проекта, чем вовремя созданный "почти работающий" прототип и своевременное финансирование дальнейшей разработки.


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


Если рассмотреть существующие браузеры, то можно прийти к выводу: общепринятым является только вариант XML+XSLT. Сегодня Namespaces поддерживаются не везде и частично, а Behaviors вообще является  специфической технологией Microsoft. И что бы ни говорили маркетологи, все ставить на MS мы не будем – совместное влияние Firefox, Mozilla и Opera не вызывает сомнений. Проверить, поддерживает ли ваш браузер XML в простейшем виде, можно, если зайти на одну из онлайн-страниц, например, http://www.w3schools.com/xml/note.xml.


Из двух возможных схем логично выбрать DTD, поскольку Schema еще не достаточно распространена, и вы можете столкнуться с проблемами совместимости. К тому же Schema сама требует DTD для собственного определения, что приводит к ненужной рекурсивной сложности.


Впрочем, соблазн использовать контроль типов данных в Schema весьма велик, так что и это решение можно считать разумным, хотя и несколько авангардным. Некоторые серверы уже сейчас используют Schema-ориентированные публичные сервисы, защищаясь таким образом от ошибочных и злонамеренных XML-пакетов. Небольшое замечание: для XML Schema почти все редакторы XML имеют специальный графический режим, в то время как DTD почти всегда приходится обрабатывать как текст.


С инструментами ситуация проще – это XMLSpy или Stylus Studio. Оба продукта являются признанными лидерами в данной области и могут оперировать многими XML-технологиями, в частности XSLT. Также может оказаться полезным OxygenXML, весьма полный и удобный продукт, причем работающий с многими платформами.


А теперь вернемся к HTML-документу, который является прообразом нашего отчета. Это уже отличный материал для создания XSLT. Собственно, XSLT обозначает eXtensible Stylesheet Language Transformer, то есть набор правил, по которым из одного XML-документа строится другой документ, хоть и не обязательно XML. "Другим" чаще всего бывает XHTML, который уже может быть непосредственно отображен в браузере. Рассмотрим на небольшом примере, как это выглядит на практике  (в качестве HTML-редактора рекомендуется использовать Stylus Studio, а не MS Word, поскольку в последнем случае вы не сможете контролировать все тэги XHTML).


Допустим, заказчик утвердил макет (рис). Все надписи приведены на английском не случайно – это реальный проект, сделанный для одной американской компании с документооборотом в шесть тысяч счетов в сутки, так что ничего не пришлось придумывать.

 

 

Можно, конечно, распечатать этот макет, и, орудуя фломастером или маркером, подчеркивать различные фрагменты и называть их различными именами. Но человек сведущий запускает для этого Altova StyleVision. В этой замечательной программе есть такой полезный для нас пункт, как HTML Import. Чтобы его не пропустили, он встречается дважды – в отдельном пункте меню и меню File. После загрузки нашего макета вы начинаете смотреть на него, как на будущий XSLT.


Дело в том, что XML представляет собой набор данных без какого-либо поведения, в том числе без какого-либо внешнего представления. Впрочем, открыв XML-файл в Internet Explorer, вы все-таки увидите довольно симпатичное “представление”. Это представление "зашито" в сам Explorer и не является свойством документа.


Документ XSL – это XML Styling Language, то есть язык для придания XML некоторого внешнего вида. Буква T обозначает (на выбор) Transition, Translation или Transformation, в любом случае это означает, что данный XSL будет использован не для отображения XML, а для трансформации одного файла в формате XML в другой, возможно, тоже XML, хотя совсем не обязательно. Можно сказать, что XSL для XML – это то же самое, что и CSS для HTML. После применения XSLT можно получить (X)HTML, то есть то, что может быть отображено в браузере. При этом современный браузер занимается такими вещами сам, без какого-либо кодирования с вашей стороны.


Единственной работой, которую вам надо выполнить, – это выделять фрагменты текста и делать HTML-Import  — Insert — Convert Selection To Elements. Только не забывайте, что в XML различаются большие и маленькие буквы: если потом в запросе или при формировании результата вы напишете по-другому, то на самом деле ничего не должно быть найдено. Фактически, некоторые инструменты игнорируют это, но так не должно быть, и рассчитывать на это не нужно, как и на то, что некоторые реализации (в частности, Microsoft) используют CR+LF для окончания строк XML: по стандарту там предусмотрен только LF – так, как это принято в Unix.


Чтобы вновь созданные тэги, особенно вложенные, не портили картину своим неуклюжим форматированием, просто два раза щелкните на элемент, и он "округлится", то есть превратится в компактный place holder.


А сейчас – несколько советов относительно правил хорошего стиля. Во-первых, не нужно искусственно углублять иерархию шаблона XML – например, если Previous Balance встречается в документе один раз, и абсолютно ясно, о чем речь, то незачем отдельно группировать Account Summary, Previous и Current. Вы всегда сможете усугубить сложность структуры, создав уровни вложенных элементов и перетащив туда элементы из одноуровневой иерархии, но для этого надо иметь веские причины. В любом случае, не надо путать графическое, визуальное положение на форме и структуру документа XML: рамка – еще не повод для сложного элемента.


Во-вторых, если есть подозрение, что данные будут обрабатываться как целое, например, данные о клиенте, то, без сомнения, группируйте их в сложный элемент. Также если нет уверенности в том, что некоторые элементы будут обработаны отдельно, разбивайте элемент на части: например, храните год, месяц и день транзакции в отдельных тэгах. Причина этого проста: после генерации XML осуществить поиск и выборку нужного элемента, а также произвести вычисления будет сложнее и уж точно значительно медленнее, так что делайте как можно больше обработки данных еще на этапе генерации XML.


Третий важный совет: хотя атрибут так же легко создать, как и элемент, никогда не используйте атрибуты, кроме совершенно необходимых случаев. Собственно, такой канонический случай только один – маркировка однотипных элементов уникальными идентификаторами, чтобы не создавать сложный элемент на ровном месте. Этот совет дается прямо на сайте разработчиков XML, и нет причин им не верить. Впрочем, XML и хорош, и плох как раз тем, что в нем "все позволено, но не все полезно".

 

Итак, мы преобразовали все потенциальные поля в элементы. Теперь,  как может показаться, меню Save должно сохранять один файл, но в этой ситуации все не так, ведь мы фактически разделили HTML на данные и представление. На самом деле StyleVision сохраняет пакет из четырех файлов: sps, внутренний формат редактора (по сути, тоже в XML-формате), файл DTD или Schema, описывающий структуру такой, какой она была видна в левом окне, XSLT, куда попадает все форматирование и прочий HTML-хлам, и, наконец, XML с данными, которые были извлечены из нашей формы. Последний файл очень важен: без него мы не сможем тестировать XSLT. А вообще, могут быть также генерированы FO, Format Objects, файл RTF и так далее – полный список смотрите в меню File.


Теперь вы открываете XML в браузере и убеждаетесь, что все выглядит точно так же, как было на макете. Поскольку построить HTML не сложнее, чем отчет в специальном редакторе, небольшие дополнительные действия компенсируются отсутствием других деяний.


Как генерировать XML – однозначно сказать нельзя, все зависит от того, насколько сложен ваш макет. Вероятно, можно использовать какой-то стандартный механизм, например, если выходную таблицу создать как результат одного или нескольких SQL-запросов или в форме хранимой процедуры. В более сложном случае придется писать собственный код – хорошая библиотека, строящая документы на основе схемы, будет очень кстати. Можно формировать XML как результат работы генератора отчета – если генератор может выводить тестовый файл, его легко заставить "рисовать" и XML.

 

Конечно, после обратного прохода от эталонного макета к формированию XML должны последовать еще два-три прохода – схемы должны быть хорошо структурированы и документированы, чтобы не возникало сомнений относительно их использования. Исходный HTML также изначально может опираться на CSS, чтобы еще более очистить XSLT и избавить XML-часть от лишних визуальных элементов. Вместо этого, возможно, вы захотите встроить в XSLT такие элементы форматирования, которые были недоступны в исходном HTML, – условные операторы, циклы, функции, сложные запросы XPath и так далее.

 

Знание – сила


Еще раз хочется подчеркнуть, что включенный в FoxPro 9 генератор отчетов уже делает все вышеописанное. Однако, как это часто бывает, мы не можем контролировать поведение продуктов “Майкрософт” на должном уровне. Как MS Word порождает совершенно непредсказуемые и часто неприемлемые HTML-документы, так и генератор отчетов пользуется собственными соображениями для называния тэгов и т.д. Поэтому сделанный вручную XML/XSLT будет всегда, или почти всегда, выглядеть более профессионально.


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


На нашем диске лежат триальные версии упоминавшихся программ – они регистрируются по сети, а триальные серийные номера вы получите по почте.

2006.04.26
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".