Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Стандарт Объектной модели документа, прежде всего, разрабатывается для документов (например, статьи и книги). Кроме того, JAXP, 1.4.2 реализации поддерживают XML-схему, что-то, что может быть важным рассмотрением для любого данного приложения.
С другой стороны, если Вы имеете дело с простыми структурами данных и если XML-схема не является большой частью Ваших планов, то можно найти, что один из более объектно-ориентированных стандартов, таких как JDOM или dom4j, лучше подходит в Вашей цели.
От запуска ДОМ был предназначен, чтобы быть нейтральным языком. Поскольку это было разработано для использования с языками, такими как C и Perl, ДОМ не использует в своих интересах объектно-ориентированные функции Java. Тот факт, в дополнение к различию между документами и данными, также помогает учесть пути, которыми обработка ДОМА отличается от обработки JDOM или dom4j структуры.
В этом разделе мы исследуем различия между моделями, базовыми те стандарты, чтобы помочь Вам выбрать тот, который является самым подходящим для Вашего приложения.
Важный пункт отъезда между моделью документа, используемой в ДОМЕ и моделью данных, используемой в JDOM или dom4j, находится в:
Это - различие в том, что составляет "узел" в иерархии данных, которая прежде всего учитывает различия в программировании с этими двумя моделями. Однако, емкость для смешанного контента, больше чем что-либо еще, учитывает различие в том, как стандарты определяют узел. Таким образом, мы запускаем, исследуя модель смешанного контента DOM.
Текст и элементы могут быть свободно смешаны в иерархии ДОМА. Такую структуру вызывают смешанным контентом в модели ДОМА.
Смешанный контент часто происходит в документах. Например, предположите, что Вы хотели представить эту структуру:
<sentence>This is an <bold>important</bold> idea.</sentence>
Иерархия узлов ДОМА выглядела бы примерно так, где каждая строка представляет один узел:
ELEMENT: sentence
+ TEXT: This is an
+ ELEMENT: bold
+ TEXT: important
+ TEXT: idea.
Отметьте, что элемент предложения содержит текст, сопровождаемый подэлементом, сопровождаемым дополнительным текстом. Это - смешивание текста и элементов, который определяет модель смешанного контента.
Чтобы обеспечить емкость для смешанного контента, узлы ДОМА по сути очень просты. В предшествующем примере "контент" первого элемента (его значение) просто идентифицирует вид узла, который это.
Новые пользователи ДОМА обычно бросаются этим фактом. После навигации к узлу <sentence> они просят "контент" узла, и ожидают получать что-то полезное. Вместо этого все, что они могут найти, является именем элемента, sentence.
Отметьте - API ДОМА Ноуда определяет nodeValue(), nodeType(), и методы nodeName(). Для первого узла элемента nodeName() возвращает sentence, в то время как nodeValue() возвращает нуль. Для первого текстового узла nodeName() возвращает #text, и nodeValue() возвращает "This is an". Важный момент - то, что значение элемента не является тем же самым как своим контентом.
В примере выше, что означает попросить "текст" предложения? Любое следующее могло быть разумным, в зависимости от Вашего приложения:
С ДОМОМ Вы свободны создать семантику, в которой Вы нуждаетесь. Однако, Вы также обязаны делать обработку, необходимую, чтобы реализовать тех семантика. Стандарты, такие как JDOM и dom4j, с другой стороны, облегчают делать простые вещи, потому что каждый узел в иерархии является объектом.
Хотя JDOM и dom4j делают скидку на элементы, смешивавшие контент, они прежде всего не разрабатываются для таких ситуаций. Вместо этого они предназначаются для приложений, где структура XML содержит данные.
Элементы в структуре данных обычно содержат или текст или другие элементы, но не обоих. Например, вот некоторый XML, который представляет простую адресную книгу:
<addressbook>
<entry>
<name>Fred</name>
<email>fred@home</email>
</entry>
...
</addressbook>
Отметьте - очень простыми структурами данных XML как этот, Вы могли также использовать пакет регулярного выражения (java.util.regex), встроенный в платформу Java в версии 1.4.
В JDOM и dom4j, после того, как Вы перемещаетесь к элементу, который содержит текст, Вы вызываете метод, такой как text(), чтобы получить его контент. Обрабатывая ДОМА, тем не менее, следует осмотреть список подэлементов, чтобы "соединить" текст узла, как Вы видели ранее - даже если тот список содержит только один элемент (ТЕКСТОВЫЙ узел).
Так для простых структур данных, таких как адресная книга, можно спасти себя немного работы при использовании JDOM или dom4j. Может иметь смысл использовать одну из тех моделей, даже когда данные технически "смешиваются", но всегда есть один (и только один) сегмент текста для данного узла.
Вот пример такой структуры, которая была бы также легко обработана в JDOM или dom4j:
<addressbook>
<entry>Fred
<email>fred@home</email>
</entry>
...
</addressbook>
Здесь, у каждой записи есть немного текста идентификации, сопровождаемого другими элементами. С этой структурой программа могла переместиться к записи, вызвать text(), чтобы узнать, кому это принадлежит, и обработайте подэлемент <email>, если это в корректном узле.
Но для Вас, чтобы получить полное понимание вида обработки Вы должны сделать, ища или управляя ДОМОМ, важно знать виды узлов, которые может очевидно содержать ДОМ.
Вот пример, который иллюстрирует этот тезис. Это - представление этих данных:
<sentence>
The &projectName; <![CDATA[<i>project</i>]]> is
<?editor: red><bold>important</bold><?editor: normal>.
</sentence>
Это предложение содержит ссылку на сущность - указатель на объект, который определяется в другом месте. В этом случае объект содержит имя проекта. Пример также содержит раздел CDATA (неинтерпретируемые данные, как данные <pre> в HTML) так же как инструкции обработки (<?...?>), которые в этом случае говорят редактору, которые красят, чтобы использовать, представляя текст.
Вот структура ДОМА для тех данных. Это является представительным для вида структуры, которую устойчивое приложение должно быть подготовлено обработать:
+ ELEMENT: sentence
+ TEXT: The
+ ENTITY REF: projectName
+ COMMENT:
The latest name we are using
+ TEXT: Eagle
+ CDATA: <i>project</i>
+ TEXT: is
+ PI: editor: red
+ ELEMENT: bold
+ TEXT: important
+ PI: editor: normal
Этот пример изображает виды узлов, которые могут произойти в ДОМЕ. Хотя Ваше приложение может быть в состоянии проигнорировать большинство из них большую часть времени, действительно устойчивая реализация должна распознать и иметь дело с каждым из них.
Точно так же процесс навигации к узлу включает подэлементы обработки, игнорирование тех, Вы не интересуетесь и осмотр тех, Вы, пока Вы не находите узел, которым Вы интересуетесь.
Программа, которая работает над фиксированным, внутренне сгенерированные данные, может позволить себе сделать упрощение предположений: та обработка инструкции, комментарии, узлы CDATA, и ссылки на сущность не будет существовать в структуре данных. Но действительно устойчивые приложения, которые работают над множеством данных - особенно данных, прибывающих из внешнего мира - должны быть подготовлены иметь дело со всеми возможными объектами XML.
("Простое" приложение будет работать только, пока входные данные содержат упрощенные структуры XML, это ожидает. Но нет никаких механизмов проверки допустимости, чтобы гарантировать, что более сложные структуры не будут существовать. В конце концов XML был специально предназначен, чтобы позволить им.)
Чтобы быть более устойчивым, приложение ДОМА должно сделать эти вещи:
Отметьте - В JAXP 1.2 вперед, синтаксический анализатор JAXP не вставляет узлы ссылки на сущность в ДОМА. Вместо этого это вставляет узел TEXT, содержащий содержание ссылки. JAXP 1.1 синтаксических анализатора, которые были встроены в версию 1.4 платформы Java Standard Edition (Java платформа SE), с другой стороны, действительно вставляет узлы ссылки на сущность. Так устойчивая реализация, которая является независимыми от синтаксического анализатора потребностями, которые будут подготовлены обрабатывать узлы ссылки на сущность.
Конечно, много приложений не должны будут волноваться о таких вещах, потому что видом данных, которые они видят, будут строго управлять. Но если данные могут прибыть из множества внешних источников, то приложение должно будет, вероятно, принять эти возможности во внимание.
Код Вы должны выполнить эти функции, дается около конца этого урока в Контенте Узла Сирчинг фора Нодезэнда Обтэйнинга. Прямо сейчас цель состоит в том, чтобы просто определить, является ли ДОМ подходящим для Вашего приложения.
Как можно видеть, когда Вы используете ДОМА, даже простая работа, такая как получение текста от узла может взять немного программирования. Так, если Ваши программы обрабатывают простые структуры данных, то JDOM, dom4j, или даже 1.4 пакета регулярного выражения (java.util.regex) может быть более подходящим для Ваших потребностей.
Для абсолютных документов и сложных приложений, с другой стороны, ДОМ дает Вам большую гибкость. И если Вы должны использовать XML-схему, с другой стороны ДОМ является способом пойти - пока по крайней мере.
Если Вы обрабатываете оба документа и данные в приложениях, Вы разрабатываете, то ДОМ может все еще быть Вашим лучшим выбором. В конце концов, после того, как Вы записали код, чтобы исследовать и обработать структуру ДОМА, довольно легко настроить это в определенной цели. Так хотя делать все в ДОМЕ означает, что необходимо только иметь дело с одним набором API, а не два.
Кроме того, стандарт ДОМА является шифруемым стандартом для модели документа в памяти. Это мощно и устойчиво, и у этого есть много реализаций. Это - существенный фактор принятия решений для многих больших установок, особенно для крупномасштабных приложений, которые должны минимизировать затраты, следующие из изменений API.
Наконец, даже при том, что текст в адресной книге, возможно, не разрешает полужирный, курсив, цвета, и размеры шрифта сегодня, однажды можно хотеть обработать эти вещи. Поскольку ДОМ обработает фактически что-либо, что Вы бросаете в это, выбирая ДОМА облегчает соответствовать требованиям завтрашнего дня Ваше приложение.
|
