Гостевая
Форум
Разделы
Главная страница
Js скрипты
Php скрипты
Html шаблоны
Книги по Web дизайну
Статьи


Главная страница статей --> Хитрости при программировании php, заметки по базам данных

Perl & XML. Библиотека программиста

Источник: realcoding.net

[2 страница]

ХМL-процессоры



Теперь, когда была рассмотрена «простая сторона» XML, приступим к изучению некоторых особенностей этого языка. Эти особенности следует учитывать при работе с XML и Perl.


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


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


В мире Perl подобное поведение определяется с помощью Perl-модулей: как правило, в случае, когда требуется обработка XML-кода, осуществляемая с помощью инструкции use. При этом используется существующий пакет, обеспечивающий доступ программиста к объектно-ориентированному интерфейсу. Начало обработки XML-кода во многих программах на языке Perl, располагающих соответствующими возможностями, определяется с помощью анализатора XML::Parser (либо другой подобной программы). По прошествии небольшого периода времени вся «черновая работа» по разбору XML-кода поручается другим, ранее написанным модулям. Код, составленный программистами, определяет порядок предварительной и завершающей обработки.



Пользуйтесь готовыми модулями



К одной из сильных сторон Perl можно отнести то, что этот язык поддерживается сообществом его сторонников во всем мире. Как только программисты на языке Perl идентифицируют проблему и создают соответствующий модуль, нацеленный на ее решение, результат их деятельности становится достоянием мировой общественности. Для этой цели предназначается сеть CPAN. Основное преимущество в данном случае заключается в том, что если вы хотите создать какой-либо фрагмент кода на языке Perl, существует вероятность, что кто-либо создал его ранее, и в сети CPAN можно найти соответствующий Perl-модуль.


Однако метод «коллективного творчества», примененный по отношению к столь «юной», популярной и нетрадиционной технологии, каковой является XML, имеет свои недостатки. К моменту первого «выхода на сцену» XML в сети CPAN существовали различные Perl-модули, написанные различными программистами. По причине полной анархии все они образуют «нестройный хор», в число участников которого входят различные структуры и интерфейсы, ориентированные на достижение различных целей.


Однако не падайте духом. Времена «анархии и беспорядка», относящиеся к 1998 году, остались в прошлом. В настоящие время наблюдается некое подобие организации и стандартов. Причем инициатива исходит от сообщества Perl/XML (о чем изначально было заявлено в списке рассылки perl-xml, поддерживаемом ActiveState). Члены сообщества разрабатывали первые модули с целью создания требуемых инструментов. При этом они следовали правилам, установленным другими игроками в мире XML. К числу этих «игроков» можно отнести стандарты синтаксического анализа, SAX и DOM, а также внедренные XML-технологии, такие как XPath. Позднее появились базовые анализаторы низкого уровня. Совсем недавно возникли интересные системы (такие как XML::SAX), которые реализуют модель DWIM на уровне Perl, отображенную в разрабатываемых стандартах1.


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



Программисту на заметку



Как правило, XML-модули, находящиеся в сети CPAN, удовлетворяют потребности программистов на 90%. Конечно, оставшиеся 10% можно рассматривать как соотношение между ведущими специалистами вашей компании и «кандидатами на увольнение». Авторы книги намереваются оправдать те затраты, которые вы понесли в результате приобретения книги, путем демонстрации некоторых «ужасных» деталей, объясняющих порядок обработки в Perl XML-документов на самых низких уровнях (по сравнению с любым видом специализированной обработки текста, осуществляемой в Perl). Для начала обратимся к некоторым «азбучным истинам», которые следует учитывать в дальнейшем.


Происхождение программы не имеет значения



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


Имейте в виду, что программа требует внимания к себе в целом. Например, если была написана программа, реализующая механизм XML-RPC, лучше знать порядок использования протокола TCP, который определяет выборку и отсылку через Интернет всех XML-данных! Мы можем использовать эту программу для выполнения операций выборки и отсылки данных, однако до тех пор, пока конечный программный продукт является неизменным, так как пользователь будет испытывать потребность в чистом XML-документе, который может обрабатываться XML-процессором, лежащим в ядре программы.


Все XML-документы подобны с точки зрения структуры



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


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


XML-приложения различаются своим назначением



Любые XML-приложения определяют смысл существования произвольного XML-документа. Причем набор правил высшего уровня, которым следует произвольный XML-документ, способствует достижению некоторых полезных целей. Эти правила могут определять: заполнение файла конфигурации, подготовку передачи данных в сети иливыполнение некоторых других действий. Смысл существования XML-приложений заключается не только в том, чтобы наполнять скромные документы «высшим смыслом их предназначения». Они также требуются для определения структуры создаваемых документов в соответствии с определенной спецификацией приложений. С помощью объявления DTD облегчается достижение совместимости описанной выше структуры. Однако следует учитывать тот факт, что в распоряжении разработчика может не оказаться схемы формального подтверждения, используемой при разработке приложений. Может возникнуть потребность в создании некоторых правил проверки. Эти правила окажутся весьма полезными, например, в случае, когда требуется, чтобы ваши последователи (включая и вас самих две недели спустя) не «путались в дебрях» разработанной ранее программы. Потребуется также создать схему проверки, если необходимо будет позволить другим программистам создавать программы, обеспечивающие использование преимуществ языка XML.


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


ввод данных осуществляется с применением подходящего метода. В частности может осуществляться «прослушивание» сетевого сокета либо считывание файла с диска. Подобное поведение является весьма типичным и характерным для Perl: делайте все необходимое для получения данных;
перехваченные входные данные будут передаваться некоему типу XML-процессора. Как правило, лучше всего воспользоваться одним из анализаторов, созданным и поддерживаемым сообществом разработчиков на Perl. В качестве этих модулей может использоваться модуль XML::Simple либо более сложные модули, которые будут рассмотрены ниже;
и наконец, обратите внимание на результат обработки процессором XML-кода. Возможно, он будет продуцировать XML-код (либо HTML-код), обновлять базу данных либо отсылать электронное сообщение вашей матери. Этот пункт является определяющим при выполнении XML-приложения: просто берется код XML и выполняется некая его обработка. В книге не будут обсуждаться поистине безграничные возможности, открывающиеся в этом случае. Предмет рассмотрения составят тесные связи между XML-процессором и остальными частями вашей программы.


Особенности XML



В этом разделе затрагиваются вопросы, составляющие предмет всей книги. Именно с ними связаны проблемы, возникающие при обработке XML-документов.


Формальная корректность



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


Кодировки символов



Жизнь в XXI веке требует уделять внимание таким вопросам, как применяемые кодировки символов. Безвозвратно ушли те дни, когда содержимое web-узловв Интернете кодировалось с применением набора символов ASCII. «Героем наших дней» стал Unicode, на базе которого формируются все основные наборы символов, применяемые в Сети. В XML предполагается работа с символами Unicode, хотя существует множество способов для представления этой кодировки, включая наиболее часто используемую в Perl кодировку Unicode, UTF-8. Как правило, достаточно редко приходится задумываться о вопросах подобного рода, но нужно быть осведомленным относительно имеющихся возможностей.


Пространства имен



Не каждый может похвалиться тем, что работал с пространствами имен. Пространства имен производят разбиение кода на отдельные области, разделяя теги, разметки и объявления. В результате появляется возможность смешивать и сопоставлять различные типы документов. Идет ли речь об уравнениях в HTML-коде, либо о разметке в виде данных в XSLT-коде, использование пространств имен является оправданным. Имейте в виду, что поддержка пространств имен реализована в недавно разработанных модулях.


Объявления



По существу, объявления не входят в состав документа, а просто описывают его. Это следует принимать как данность и не стоит уделять этому вопросу повышенное внимание. Помните лишь о том, что в документах часто применяются объявления DTD, а также включаются объявления таких объектов, как сущности и атрибуты. Следует учитывать это, с тем чтобы не «наломать дров» в дальнейшем.


Сущности



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


Служебные символы



Согласно правилам, принятым в XML, все то, что не является тегом разметки, относится к разряду значащих символьных данных. Этот факт может привести к некоторым неожиданным результатам. Например, не всегда можно определенно сказать, что происходит при обработке служебных символов. По умолчанию XML-процессор сохраняет все символы — даже символы создания новых строк, которые можно включать после тегов с целью улучшения восприятия кода, либо символы пробелов, которые можно применять для создания отступов в тексте. Некоторые анализаторы иногда позволяют игнорировать пробелы, но в этом случае отсутствуют жестко установленные и простые правила.


Заканчивая обзор языков Perl и XML, можно сделать вывод, что они превосходно дополняют друг друга. И хотя в процессе работы могут появляться так называемые «ловушки», но благодаря наличию различных модулей, разработанных программистами, изучение возможностей Perl/XML будет легким и приятным.
[0.001]