Средства разработки web-страниц
Понятие и средства создания Java-апплета. Использование ActiveX объектов на web-страницах. Редакторы типа WYSIWYG. Возможности технологий COM, CORBA, XML Path. Описание содержания XML документа с помощью схем DTD. Создание меток и сущностей в DTD.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | контрольная работа |
| Язык | русский |
| Дата добавления | 06.12.2012 |
| Размер файла | 1,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Федеральное агентство по образованию
Государственное образовательное учреждение
среднего профессионального образования
Хакасский политехнический колледж
Внеаудиторная работа
по дисциплине: «Распределённые системы обработки информации»
Выполнил: студент гр. АИС-41
Урванцев А.В.
Абакан, 2009
Понятие Java-апплета. Средства создания Java-апплетов
Апплет объединяет в себе элементы сложного графического окна с легкостью использования и возможностями работы с сетями. В сущности, он является миниатюрным графическим интерфейсом пользователя, подобно Microsoft Windows или X11, который, как гарантируют разработчики, будет иметь в основном одни и те же функциональные возможности независимо от типа компьютера, им управляющего.
Апплеты очень полезны для написания прикладных программ для Интернет, потому что они могут быть вложены в HTML-документы и выполняться в броузерах Web, допускающих использование языка Java, - например, Netscape Navigator 2.0. Чтобы создать свои собственные апплеты, нужно расширить класс Applet и сослаться на новый класс на Web-странице. Давайте рассмотрим апплет "Hello World", подобный апплету, "Основы программирования на Java".
Пример. Апплет "Hello World".
import java.applet.*;
import java.awt.*;
public class HelloWorldApplet extends Applet {
public void init() {
resize(250,250);
}
public void paint(Graphics g) {
g.drawString("Hello world!",25,25);
}
}
Апплет "Hello World" расширяет класс Applet, а это означает, что все методы и переменные, доступные классу Applet, доступны и нашему расширению этого класса. К примеру, взяв два из этих методов - init и paint, - мы можем изменить их заданное по умолчанию поведение так, чтобы они делали то, что нам нужно. Рассмотрим HTML-код для Web-страницы, которая содержит апплет "Hello World".
Пример. Web-страница "Hello World".
<HTML>
<HEAD>
<TITLE>Hello World Applet</TITLE>
</HEAD>
<BODY>
<APPLET CODE="HelloWorldApplet.class"
WIDTH=250 HEIGHT=250>
</APPLET>
</BODY>
</HTML>
Стадии выполнения апплета
Когда Java-совместимый броузер Web загружает класс Applet, сначала он распределяет память для апплета и глобальных переменных. Затем выполняется метод init. (Вообще, программисты используют метод init, чтобы инициализировать глобальные переменные, получить ресурсы из сети и установить интерфейс пользователя.) После этого броузер вызывает метод start. Если часть броузера, содержащего апплет, видима (что обычно и случается, когда апплет только начинает свою работу), вызывается метод paint. Если пользователь уходит со страницы, содержащей апплет, броузер вызывает метод stop. Когда пользователь возвращается на страницу с апплетом, метод start, так же как и метод paint, вызывается снова. Следующий фрагмент кода иллюстрирует работу апплета в случае, если пользователь покидает страницу и затем возвращается на нее.
Пример. Апплет, считающий обращения к странице.
import java.applet.*;
import java.awt.*;
public class Count extends Applet {
int InitCount=0;
int StartCount=0;
int StopCount=0;
int PaintCount=0;
public void init() {
resize(250,75);
InitCount = InitCount + 1;}
public void start() {
StartCount = StartCount + 1;}
public void stop() {
StopCount = StopCount + 1;}
public void paint(Graphics g) {
PaintCount++;
String Output = new String(
"Inits: "+InitCount+
" Starts: "+StartCount+
" Stops: "+StopCount+
" Paints: "+PaintCount);
g.drawString(Output,25,25); } }
Одна из причин популярности World Wide Web - легкость, с которой авторы могут добавлять к своим Web-страницам изображения и звук, просто включая в код страницы указатели на местоположение графических и звуковых файлов, которые они хотят использовать. Использование языка Java дает еще более простой и намного более мощный способ. HTML - язык описания документа; Java - добротный язык программирования. Ваши Java-апплеты могли бы использовать изображения как графические пиктограммы или спрайты в игре аркадного стиля. Следующий Java-апплет принимает из сети файл с изображением и звуком и отображает их.
Пример. Апплет для Web.
import java.applet.*;
import java.awt.*;
import java.net.*;
public class WebApplet extends Applet {
private Image myImage;
private AudioClip mySound;
private URL ImageURL;
private URL SoundURL;
public void init() {
resize(250,250);
try {
// привязываем URL к ресурсам
ImageURL = new
URL("http://www.vmedia.com/vvc/onlcomp/java/chapter5/images/sample.gif");
SoundURL = new URL("http://www.vmedia.com/vvc/onlcomp/
java/chapter5/sounds/sample.au");}
// следим за правильностью URL
catch (MalformedURLException e) {}
// загружаем изображение
myImage = getImage(ImageURL);
// загружаем звук
mySound = getAudioClip(SoundURL);}
public void start() {
// запускаем проигрывание звука
mySound.loop();}
public void stop() {
// останавливаем проигрывание звука
mySound.stop();}
public void paint(Graphics g) {
// выводим изображение
g.drawImage(myImage,0,0,this);
}
}
Использование ActiveX объектов на web-страницах
Технология ActiveX базируется на технологии Microsoft COM (Component Object Model - модель компонентных объектов), позволяющей создавать и использовать программные компоненты, предоставляющие различные сервисы другим приложениям, компонентам и операционной системе. COM представляет собой одну из реализаций концепции распределенных вычислений, базирующейся в общем случае на предоставлении возможности приложениям использовать для расширения своей функциональности готовые компоненты и объекты (иногда они называются сервисами). Технология COM позволяет использовать объектно-ориентированный подход не в рамках одного приложения, а в рамках операционной системы, но, в отличие от стандартных классов, определенных в исходном тексте и реализуемых как объекты в адресном пространстве одного процесса, эти компоненты могут в общем случае располагаться в адресных пространствах разных процессов и даже на разных компьютерах.
В настоящее время существуют три типа спецификаций COM, определенных Microsoft и включающих большое количество интерфейсов и функций:
· OLE-документы - составные документы, содержащие внедренные или связанные объекты. Эта спецификация описывает правила создания контейнеров для таких документов с "активацией по месту". Отметим, что компонент OLEContainer Delphi и C++Builder создан с учетом этой спецификации (этой теме будет посвящена одна из следующих статей данного цикла).
· OLE Automation. Эта спецификация описывает, как создать сервер и контроллер, управляющий его поведением с помощью скриптов или макросов. Эта спецификация также поддерживается Delphi и C++Builder (об этом также пойдет речь в ближайших статьях данного цикла).
· Управляющие элементы ActiveX, использующие специальный вариант протокола Automation (о них-то и пойдет речь в данной статье).
Использование COM, и, в частности, технологии ActiveX, позволяет обеспечить создание приложений, собираемых из готовых компонентов - элементов управления ActiveX, отличающееся от привычной пользователям C++Builder или Delphi разработки приложений с помощью VCL-компонентов тем, что такая "сборка" не зависит от того, на каком языке написаны как готовые компоненты, так и использующее их приложение - лишь бы средство разработки поддерживало возможность использования таких компонентов в разрабатываемом приложении (такое приложение обычно называется контейнером).
Элементы управления ActiveX представляют собой библиотеки, содержащие исполняемый код. Как было сказано выше, эти библиотеки могут быть использованы в различных приложениях как встроенные элементы управления, поэтому они обладают свойствами, событиями и методами, доступными посредством автоматизации. Современные средства разработки, как правило, позволяют включать такие элементы в создаваемые с их помощью приложения. Помимо этого, элементы управления ActiveX нередко используются в качестве расширений web-броузеров с целью придания им дополнительной функциональности, например, для отображения документов, отличных от поддерживаемых данным броузером.
Как любой COM-сервер, элемент управления ActiveX обладает уникальным идентификатором GUID и должен быть зарегистрирован в реестре. На основании этой записи может быть осуществлен поиск местоположения файла с расширением *.ocx, содержащего его реализацию.
Таким образом, создав элемент управления ActiveX, обладающий интересующей Вас функциональностью, Вы можете в дальнейшем позволить его пользователям встраивать этот элемент в свои приложения (например, написанные на Visual Basic, PowerBuilder, Delphi, C++Builder и др.), отображать его в web-броузере в составе выгруженной с Вашего web-сервера HTML-страницы, включать его в состав документов MS Office, при этом Вы не обязаны предоставлять исходный текст этого компонента.
Спецификация ActiveX представляет собой набор правил (а именно описание стандартных интерфейсов), с помощью которых следует создавать такие элементы управления. Отметим, что текущая версия этой спецификации учитывает возможность использования в качестве контейнера web-броузеров и необходимость загрузки элементов ActiveX с удаленных web-серверов с их автоматической регистрацией.
Пример использования ActiveX:
web страница редактор документ
Краткий обзор WYSIWYG средств разработки web-страниц
Редакторы типа WYSIWYG характеризуются тем, что позволяют пользователю создавать оформление страницы, после чего программа автоматически пишет код к этой странице, вот несколько примеров подобных программ.
Microsoft FrontPage
Microsoft FrontPage, входящий в пакет Microsoft Office, является классическим WYSIWYG-редактором, в котором, однако, присутствует возможность ручной правки кода.
Интерфейс программы во многом напоминает таковой и Microsoft Word, что нисколько не удивляет - унификация внешнего вида поможет новичкам быстрее освоить основные возможности FrontPage.
В программе имеется три режима работы с документом: Normal, HTML и Preview. В режиме Normal веб-страница представляет собой обычный текстовый файл с возможностью редактирования всех элементов - от текста до картинок.
Macromedia Dreamweaver MX 2004
Macromedia Dreamweaver MX 2004 позволяет ожидать многого от этой HTML-редактора. И действительно, возможности Macromedia Dreamweaver MX 2004 впечатляют. После установки пользователя просят выбрать внешний вид программы, который отличается в зависимости от подхода к созданию веб-документов. При выборе "Code" интерфейс программы будет подстроен под нужды кодировщика, а при выборе "Design" - соответственно, дизайнера. Впрочем, всегда имеется возможность для переключения между этими двумя режимами, а также доступен третий, комбинированный режим - рабочая область программы делится на две части.
Macromedia HomeSite
Macromedia HomeSite, пожалуй, является одним из самых распространенных средств редактирования HTML-документов среди пользователей, предпочитающих кодировать страницы вручную. Вместе с тем, HomeSite позволяет значительно ускорить сам процесс создания и облегчить работу разработчика.
Технология COM. Возможности технологии
COM (англ. Component Object Model -- Объектная Модель Компонентов; произносится как [ком]) -- это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Технология воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Технология COM в принципе является универсальной и платформо-независимой, но закрепилась в основном на операционных системах семейства Windows. В современных версиях Windows COM используется очень широко. На основе COM также было создано множество других стандартов: OLE Automation, ActiveX, DCOM, COM+.
Основным понятием, которым оперирует технология COM, является COM-компонент. Программы, построенные на технологии COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы -- наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом.
Windows API предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC и, особенно, ATL/WTL предоставляют гораздо более гибкие и удобные средства для работы с COM. Библиотека ATL от Майкрософт до сих пор остаётся самым популярным средством создания COM-компонентов. Но, зачастую, COM-разработка остаётся ещё довольно сложным делом, программистам приходится вручную выполнять многие рутинные задачи, связанные с COM (особенно это заметно в случае разработки на C++). Впоследствии (в технологиях COM+ и особенно.NET) Майкрософт попыталась упростить задачу разработки COM-компонентов.
В составе Windows 2000 была выпущена технология COM+, которая расширяла возможности разработчиков COM-компонентов, предоставляя им некоторые готовые услуги, например:
улучшенную поддержку потоков;
доступ к контексту, в котором выполняется компонент (например, компоненты, используемые в ASP, могут с этой возможностью получить доступ к внутренним объектам той страницы, на которой они выполняются).
COM+ объединяет компоненты в так называемые приложения COM+, что упрощает администрирование и обслуживание компонентов. Безопасность и производительность -- основные направления усовершенствований COM+. Некоторые идеи, заложенные в основу COM+, были также реализованы в Microsoft.NET.
В 2002 году была официально выпущена платформа Microsoft.NET, которая на сегодняшний день объявлена Майкрософт рекомендуемой основой для создания приложений и компонентов под Windows. По этой причине в.NET включены и средства, позволяющие обращаться к компонентам COM из приложений.NET, и наоборот. По словам представителей Майкрософт, COM (точнее, COM+) и.NET являются отлично взаимодополняющими технологиями.
Технология CORBA. Возможности технологии
CORBA - наиболее развитая на сегодняшний день объектная технология распределенного программирования (http://www.corba.org/). CORBA позволит Вам создавать распределенные в пространстве Сети компоненты, причем эти компоненты могут быть написаны на различных языках программирования (например, С и Java), работать на различных операционных системах (например, Linux и Windows NT), просто определяя интерфейсы друг друга и удаленно вызывая открытые методы объектов, из которых состоят Ваши компоненты. Стандарт CORBA разрабатывается крупнейшим на планете консорциумом OMG и есть достаточно много хороших реализаций стандарта для различных платформ и языков (часть реализаций представляются с открытыми исходными текстами (http://www.opensource.org/), напр. http://www.openorb.org/ (Java), ORBit (C)). CORBA может стать основой для будущей технологии компонентного программирования.
CORBA включает в себя простой язык описания интерфейсов объектов - IDL (Interface Definition Language), что позволяет отделять описания интерфейсов от их реализации и обертывать в CORBA существующие приложения. Также следует сказать, что любой компонент может быть как клиентом, так и сервером одновременно. Можно вызывать методы объектов, расположенных в этой же программе (напр. в параллельном потоке (thread)), в программе на этом же хосте в Сети, на любом хосте или устройстве в Сети (напр. в сотовом телефоне или автомобиле). Вообще, чтобы вызывать методы удаленного объекта, нужно иметь как минимум описание его на IDL и так называемую объектную ссылку на него.
Технология CORBA (Common Object Request Broker Architecture), разрабатываемая OMG (Object Managment Group) с 1990-го года, позволяет вызывать методы у объектов, находящихся в сети где угодно, так, как если бы все они были локальными объектами.
На рисунке показана основная структура CORBA 2.0 ORB.
Dynamic Invocation Interface (DII): позволяет клиенту находить сервера и вызывать их методы во время работы системы. IDL Stubs: определяет, каким образом клиент производит вызов сервера. ORB Interface: общие как для клиента, так и для сервера сервисы. IDL Skeleton: обеспечивает статические интерфейсы для объектов определенного типа. Dynamic Skeleton Inerface: общие интерфейсы для объектов, независимо от их типа, которые не были определены в IDL Skeleton. Object Adapter: осуществляет коммуникационное взаимодействие между объектом и ORB.
К основным достоинствам CORBA можно отнести межязыковую и межплатформенную поддержку. Хотя CORBA-сервисы и отнесены к достоинствам технологии CORBA, их в равной степени можно одновременно отнести и к недостаткам CORBA, ввиду практически полного отсутствия их реализации.
Практически, для создания распределенных компонентов при программировании в CORBA выполняются обычно как минимум следующие шаги:
· Проектируются распределенные компоненты;
· Описываются интерфейсы открытых объектов этих компонентов на языке IDL;
· Создаются реализации компонентов (объекты и их клиенты);
· Тестирование компонентов в распределенной среде;
· Распределяются компоненты по нужным точкам в Сети.
Описание возможного содержания XML документа с помощью схем DTD
XML Schema призвана обеспечить богатую грамматическую структуру для XML-документов и преодолеть ограничения, присущие DTD. XML Schema выразительнее DTD. Первые три листинга производят краткое сравнение различных путей представления элементов. Листинг 1 показывает фрагмент XML-документа. Листинг 2 демонстрирует объявление этих двух элементов в синтаксисе DTD, а Листинг 3 соответствующий синтаксис XML Schema. Заметьте, что синтаксис в Листинге 3 совпадает с синтаксисом XML. При использовании XML Schema элемент InvoiceNo является положительным целым, а элемент ProductID состоит из одной буквы от A до Z, сопровождаемой шестью цифрами.
Листинг 1: Фрагмент XML-документа <InvoiceNo>123456789</InvoiceNo> <ProductID>J123456</ProductID> Листинг
2: Фрагмент DTD, описывающий элементы из Листинга 1 <!ELEMENT InvoiceNo (#PCDATA)> <!ELEMENT ProductID (#PCDATA)>
Листинг 3: Фрагмент XML Schema, описывающий элементы из Листинга <element name='InvoiceNo' type='positive-integer'/> <element name='ProductID' type='ProductCode'/> <simpleType name='ProductCode' base='string'> <pattern value='[A-Z]{1}d{6}'/></simpleType>
Листинг 4: Собственные и используемые пространства имен <!--XML Schema fragment in file schema1.xsd--> <xsd:schema targetNamespace='http://www.SampleStore.com/Account' xmlns:xsd='http://www.w3.org/1999/XMLSchema' xmlns:ACC='http://www.SampleStore.com/Account'> <xsd:element name='InvoiceNo' type='xsd:positive-integer'/> <xsd:element name='ProductID' type='ACC:ProductCode'/> <xsd:simpleType name='ProductCode' base='xsd:string'> <xsd:pattern value='[A-Z]{1}d{6}'/> </xsd:simpleType>
В XML Schema из Листинга 4 имя targetNamespace представлено как http://www.SampleStore.com/Accountt и содержит имена InvoiceNo, ProductID, и ProductCode. Имена schema, element, simpleType, pattern, string, и positive-integer принадлежат используемому пространству имен http://www.w3.org/1999/XMLSchema, сокращенному до аббревиатуры xsd с помощью объявления xmlns. В псевдониме xsd нет ничего особенного; мы могли выбрать любое имя. Для удобства и простоты далее в статье мы используем xsd для обращения к пространству имен http://www.w3.org/1999/XMLSchema и опускаем характеристику xsd в некоторых фрагментах кода.
В этом примере targetNamespace также оказывается одним из используемых пространств имен, так как имя ProductCode использовано при определении других имен. Элементы, имеющие вложенные элементы, должны иметь сложный тип В XML-документе элемент может включать другие элементы. В DTD такое требование выражено напрямую. В XML Schema вместо этого определяется элемент, имеющий заданный тип, и этот тип может содержать объявления других элементов и атрибутов. См. Tаблицу 1 для простого примера.
Таблица 1: Сравнение сложных типов данных в DTD и XML Schema.
|
XML-документ |
|
|
<Book> <Title>Cool XML<Title> <Author>Cool Guy</Author> </Book> |
|
|
DTD |
|
|
<!ELEMENT Book (Title, Author)> <!ELEMENT Title (#PCDATA)> <!ELEMENT Author (#PCDATA)> |
|
|
XML Schema |
|
|
<element name='Book' type='BookType'/> <complexType name='BookType'> <element name='Title' type='string'/> <element name='Author' type='string'/> </complexType> |
Хотя код XML в Tаблице 1 соответствует фрагментам и DTD и XML Schema, между ними есть большое различие. В DTD все элементы глобальные, тогда как XML Schema в этой таблице позволяет локальные элементы Title и Author в контексте элемента Book. Для точного дублирования эффекта объявлений DTD в XML Schema элементы Title и Author должны иметь глобальную область видимости, как в Листинге 9. Атрибут ref элемента element позволяет Вам обращаться к ранее объявленным элементам. Листинг 9: Сложный тип, определенный с помощью глобальных простых типов <element name='Title' type='string'/> <element name='Author' type='string'/> <element name='Book' type='BookType'/> <complexType name='BookType'> <element ref='Title'/> <element ref='Author'/> </complexType>
В примерах Таблицы 1 и Листинга 9 BookType является глобальным и может использоваться для определения других элементов. В отличие от этого, Листинг 10 определяет BookType локально в элементе Book и, кроме того, делает его неименованным. Заметьте, что фрагмент XML-документа в Таблице 1 соответствует всем трем фрагментам схемы в Таблице 1, Листинге 9 и Листинге 10.
Листинг 10: Скрытие BookType как локального типа <element name='Title' type='string'/> <element name='Author' type='string'/> <element name='Book'> <complexType> <element ref='Title'/> <element ref='Author'/> </complexType> </element>
Определение элементов с помощью схем DTD
Накладывание сложных условий на элементы
XML Schema предоставляет гораздо большую гибкость для задания условий, налагаемых на модель содержания элементов, чем DTD. На простейшем уровне, как в DTD, вы можете связывать атрибуты с элементами и определитьколичество вхождений элементов( только одно, нуля или одного (?), нуля или более (*), или одного или более (+) элементов из данного набора. В XML Schema вы можете выразить также дополнительные ограничения, используя, например, атрибуты minOccurs и maxOccurs элемента element, а также с помощью элементов choice, group, и all.
Листинг 11: Выражение ограничений на типы элементов <element name='Title' type='string'/> <element name='Author' type='string'/> <element name='Book'> <complexType> <element ref='Title' minOccurs='0'/> <element ref='Author' maxOccurs='2'/> </complexType> </element>
В Листинге 11 должен быть хотя бы один, но не более двух, авторов в элементе Book. Значением по умолчанию minOccurs и maxOccurs будет 1 для элемента element. Элемент choice позволяет появится в примере только одному из своих дочерних элементов. Другой элемент, all, выражает ограничение, определяющее, что все дочерние элементы в группе могут появляться однажды или не появляться вовсе, и что они могут появляться в любом порядке. Листинг 12 выражает ограничение, обязывающее и Title и Author появляться в любом порядке в Book или не появляться вообще. Такие ограничения трудны для выражения в DTD. Листинг 12: Индикация того, что для элемента должны быть определены все типы <xsd:element name='Title' type='string'/> <xsd:element name='Author' type='string'/> <xsd:element name='Book'> <xsd:complexType> <xsd:all> <xsd:element ref='Tile'/> <xsd:element ref='Author'/> </xsd:all> </xsd:complexType> </xsd:element>
Мы охватили наиболее фундаментальные понятия, необходимые для определения элементов в XML Schema, дав представление о его возможностях с помощью простых примеров. Но имеется и множество гораздо более мощных механизмов:
XML Schema включает в себя расширенную поддержку наследования типов, дающего возможность повторно использовать ранее определенные структуры. Используя конструкцию faset, вы можете получить новые типы, представляющие подмножества значений других типов. В примере для этой статьи тип ProductCode был определен с использованием типа pattern. Подтип может также добавить объявления элементов и атрибутов к базовому типу.
Некоторые механизмы могут контролировать, может ли подтип вообще быть определен или замещен в конкретном документе. Например, возможно выразить тот факт, что InvoiceType (тип номера счета-фактуры) не может иметь подтипы, то есть никто не сможет определить новую версию InvoiceType. Вы можете также выразить то, что в конкретном контексте не может быть замещен ни какой подтип типа ProductCode.
Объявляя элемент или тип абстрактным, XML Schema обеспечивает механизм для его принудительной замены.
Для удобства, группы атрибутов и элементов могут быть определены и поименованы. Это дает возможность повторного использования путем последующего обращения к группам.
XML Schema предлагает три элемента - appInfo, documentation и annotation - для аннотирования схем как для читателей (documentation), так и для приложений (appInfo).
Вы можете выразить ограничение уникальности, основанное на определенных атрибутах дочерних элементов.
Определение элемента
Элемент в DTD определяется с помощью дескриптора !ELEMENT, в котором указывается название элемента и структура его содержимого.
Например, для элемента <flower> можно определить следующее правило:
<!ELEMENT flower PCDATA>
Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.
В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым (например, <red/>), вторая - на то, что содержимое элемента специально не описывается.
Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ?:
<!ELEMENT issue (title, author+, table-of-contents?)>
В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|":
<!ELEMENT flower (PCDATA | title )*>
Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться.
Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом "|" список элементов.
Пример корректного XML- документа:
<?xml version="1.0"?>
<! DOCTYPE journal [
<!ELEMENT contacts (address, tel+, email?)>
<!ELEMENT address (street, appt)>
<!ELEMENT street PCDATA>
<!ELEMENT appt (PCDATA | EMPTY)*>
<!ELEMENT tel PCDATA>
<!ELEMENT email PCDATA]>...
<contacts><address>
<street>Marks avenue</street>
<appt id="4">
</address>
<tel>12-12-12</tel>
<tel>46-23-62</tel>
<email>info@j.com</email>
</contacts>
Определение атрибутов с помощью схем DTD
В XML- документах DTD определяет набор действительных элементов, идентифицирует элементы, которые могут находиться в других элементах, и определяет действительные атрибуты для каждого из них. Синтаксис DTD весьма своеобразен и от автора-разработчика требуются дополнительные усилия при создании таких документов(сложность DTD является одной из причин того, что использование SGML, требующего определение DTD для любого документа, не получило столь широкого распространения как, например, HTML). Как уже отмечалось, в XML использовать DTD не обязательно - документы, созданные без этих правил, будут правильно обрабатываться программой-анализатором, если они удовлетворяют основным требованиям синтаксиса XML. Однако контроль за типами элементов и корректностью отношений между ними в этом случае будет полностью возлагаться на автора документа. До тех пор, пока грамматика нашего нового языка не описана, его сможем использовать только мы, и для этого мы будем вынуждены применять специально разработанное программное обеспечение, а не универсальные программы-анализаторы.
В DTD для XML используются следующие типы правил: правила для элементов и их атрибутов, описания категорий(макроопределений), описание форматов бинарных данных. Все они описывают основные конструкции языка - элементы, атрибуты, символьные константы внешние файлы бинарных данных.
Для того, чтобы использовать DTD в нашем документе, мы можем или описать его во внешнем файле и при описании DTD просто указать ссылку на этот файл или же непосредственно внутри самого документа выделить область, в которой определить нужные правила. В первом случае в документе указывается имя файла, содержащего DTD- описания:
<?xml version="1.0" standalone="yes" ?>
<! DOCTYPE journal SYSTEM "journal.dtd">...Внутри же документа DTD- декларации включаются следующим образом:...<! DOCTYPE journal [
<!ELEMENT journal (contacts, issues, authors)>
В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML- процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes", то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes", то использование внешних DTD описаний будет запрещено.
Определение атрибутов
Списки атрибутов элемента определяются с помощью ключевого слова !ATTLIST. Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <article> могут быть определены следующие атрибуты:
<!ATTLIST article
id ID #REQUIRED
about CDATA #IMPLIED
type (actual | review | teach ) 'actual' ''>
В данном примере для элемента article определяются три атрибута: id, about и type, которые имеют типы ID(идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:
· CDATA - содержимым документа могут быть любые символьные данные
· ID - определяет уникальный идентификатор элемента в документе
· IDREF (IDREFS )- указывает, что значением атрибута должно выступать названиет(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
· ENTITY (ENTITIES) - значение атрибута должно быть названиемт(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе
· NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово (т.е. этот параметр является ограниченным вариантом CDATA)
· Список допустимых значений - определяется список значений, которые может иметь данный атрибут.
Также в определении атрибута можно использовать следующие параметры:
· #REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
· #IMPLIED - атрибут не является обязательным
· #FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
· Значение - задает значение атрибута по умолчанию
Определение компонентов(макроопределений)
Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD- компоненты при помощи инструкции !ENTITY:
<!ENTITY hello ' Мы рады приветствовать Вас!' >
Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello, которое будет заменено на строчку "Мы рады приветствовать Вас"
В общем случае, внутри DTD можно задать три типа макроопределений:
Внутренние макроопределения - предназначены для определения строковой константы, с их помощью можно организовывать ссылки на часто изменяемую информацию, делая документ более читабельным. Внутренние компоненты включаются в документ при помощи амперсанта &
В XML существует пять предустановленных внутренних символьных констант:
· &lt - символ "<"
· &gt - символ ">"
· &amp - символ "&"
· &apos - символ апострофа "&apos"
· &quot - символ двойной кавычки """
Внешние макроопределения - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования макроса будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются и используются внешними программами
<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>
Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD- правила. Например, для следующего фрагмента документа:
<!ELEMENT name (PCDATA)>
<!ELEMENT title (PCDATA | name)*>
<!ELEMENT author (PCDATA | name)*>
<!ELEMENT article (title, author)*>
<!ELEMENT book (title, author)*>
<!ELEMENT bookstore (book | article)*>
<!ELEMENT bookshelf (book | article)*>можно использовать более короткую форму записи:
<!ELEMENT name (PCDATA)>
<! ENTITY %names 'PCDATA | name'>
<!ELEMENT article (%names;)*>
<!ELEMENT book (%names;)*>
<!ENTITY %content 'book | article'>
<!ELEMENT bookstore (%content;)*>
<!ELEMENT bookshelf (%content;)*>
Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:
<!ENTITY %itemattr 'id ID #IMPLIED src CDATA'>
<!ENTITY %bookattr "ISDN ID #IMPLIED type CDATA'>
<!ENTITY %artattr " size CDATA'>
<!ELEMENT book (title, author,content)*>
<!ATTLIST book %itemattr %bookattr;>
<!ELEMENT article (title, author, content)*>
<!ATTLIST article %itemattr %artattr;>
Типизация данных. Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент <last-modified>10.10.98</last-modified>, то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.
Если в качестве программы на стороне клиента используется верифицирующий XML-процессор, то информацию о типе можно передавать при помощи специально созданного для этого атрибута элемента, имеющего соответствующее DTD- определение. В процессе разбора программа-анализатор передаст значение этого атрибута клиентскому приложению, которое сможет использовать эту информацию должным образом. Например, чтобы указать, что содержимое элемента должно быть длинным целым, можно использовать следующее DTD- определение:
<!ELEMENT counter (PCDATA)><!ATTLIST counter data_long CDATA #FIXED "LONG">
Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении.
Вот пример XML- документа, в котором используются несколько элементов с различными типами данных:
<!ELEMENT price (PCDATA)>
<!ATTLIST price data_currency CDATA #FIXED "CURRENCY">
<!ELEMENT rooms_num (PCDATA)>
<!ATTLIST rooms_num data_byte CDATA #FIXED "BYTE">
<!ELEMENT floor (PCDATA)>
<!ATTLIST floor data_byte CDATA #FIXED "INTEGER">
<!ELEMENT living_space (PCDATA)>
<!ATTLIST living_space data_float CDATA #FIXED "FLOAT">
<!ELEMENT counter (PCDATA)>
<!ATTLIST counter data_long CDATA #FIXED "LONG">
<!ELEMENT is_tel (PCDATA)>
<!ATTLIST is_tel data_bool CDATA #FIXED "BOOL">
<!ELEMENT house (rooms_num, floor,living_space, is_tel, counter, price)>
<!ATTLIST house id ID #REQUIED>...
<house id="0">
<rooms_num>5</rooms_num><floor>2</floor>
<living_space>32.5</living_space>
<is_tel>true</is_tel>
<counter>18346</counter>
<price>34 р. 28 к.</price></house>...
Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD. В заключении хотелось бы отметить, что DTD предоставляет нам весьма удобный механизм осуществления контроля за содержимым документа. На сегодняшний день, практически все программы просмотра документов Интернет используют DTD-правила. Однако это далеко не единственный способ проверки корректности документа. В настоящий момент в W3 консорциуме находится на рассмотрении новый стандарт языка описания структуры документов, называемый схемами данных. Следующий раздел посвящен работе с ними.
Создание меток и сущностей в DTD
Определение: XML документ может состоять из одной или нескольких единиц размещения, называемых сущностями. Все сущности имеют содержание (исключение составляют сущность документа и внешний набор DTD) и идентифицируются по имени). Каждый XML документ имеет ровно одну сущность, называемую сущностью документа, которая служит стартовой точкой для XML процессора и может содержать документ целиком.
Определение: Ссылка на символ относится к определенному символу из набора ISO/IEC 10646, например, к такому символу, который невозможно получить непосредственно с имеющихся устройств ввода.]
Ссылка на символ
|
[66] |
CharRef |
::= |
'&#' [0-9]+ ';' |
||
|
| '&#x' [0-9a-fA-F]+ ';' |
[WFC: Допустимый символ] |
Ссылка на сущность
|
[67] |
Reference |
::= |
EntityRef | CharRef |
||
|
[68] |
EntityRef |
::= |
'&' Name ';' |
[WFC: Декларированная сущность] |
|
|
[VC: Декларированная сущность] |
|||||
|
[WFC: Разобранная сущность] |
|||||
|
[WFC: Отсутствие рекурсии] |
|||||
|
[69] |
PEReference |
::= |
'%' Name ';' |
[VC: Декларированная сущность] |
|
|
[WFC: Отсутствие рекурсии] |
|||||
|
[WFC: В DTD] |
Декларация сущности
|
[70] |
EntityDecl |
::= |
GEDecl | PEDecl |
|
|
[71] |
GEDecl |
::= |
'<!ENTITY' S Name S EntityDef S? '>' |
|
|
[72] |
PEDecl |
::= |
'<!ENTITY' S '%' S Name S PEDef S? '>' |
|
|
[73] |
EntityDef |
::= |
EntityValue | (ExternalID NDataDecl?) |
|
|
[74] |
PEDef |
::= |
EntityValue | ExternalID |
Внутренние сущности
Определение: Если сущность декларирована как EntityValue, то она называется внутренней сущностью. Для этой сущности отсутствует размещаемый отдельно физический объект, а нее содержание определяется в декларации. Заметим, что в строковом значении сущности для создания приемлемого текста замены может потребоваться некоторая обработка ссылок на сущность и символ.
Внутренняя сущность является разобранной сущностью.
Пример декларации внутренней сущности:
<!ENTITY Pub-Status "This is a pre-release of the specification.">
Внешние сущности
Определение: Если сущность не является внутренней, это внешняя сущность, декларируемая следующим образом:]
Декларация внешней сущности
|
[75] |
ExternalID |
::= |
'SYSTEM' S SystemLiteral |
||
|
| 'PUBLIC' S PubidLiteral S SystemLiteral |
|||||
|
[76] |
NDataDecl |
::= |
S 'NDATA' S Name |
[VC: Декларированная нотация] |
Обработка XML процессором сущностей и ссылок
В представленной далее таблице собраны сведения о контексте, в котором могут появиться ссылки на символы, ссылки на сущность, а также вызовы неразобранных сущностей, и какая в каждом случае потребуется реакция от XML процессора. Записи в левой колонке описывают распознаваемый контекст:
Ссылка в содержимом. Ссылка в любом месте элемента в интервале между начальным и конечным тэгами. Соответствует незавершенному (nonterminal) контенту.
Ссылка в значении атрибута
Ссылка либо в значении атрибута начального тэга, либо в значении по умолчанию из декларации атрибута. Соответствует незавершенному AttValue.
Значение атрибута
Это не ссылка, а лексема типа Name. Выступает либо как значение атрибута, декларированного с типом ENTITY, либо как одна из лексем, перечисленных через пробел в значении атрибута, декларированного с типом ENTITIES.
Ссылка в значении сущности
Ссылка из параметра или строкового значения внутренней сущности, находящихся в декларации сущности. Соответствует незавершенной EntityValue.
Ссылка во внутреннем или внешнем наборе DTD, не попавшая в конструкции EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, а также содержимое игнорируемой условной секции.
Таблица 2.
|
Тип сущности |
Символ |
|||||
|
Параметр |
Внутренняя общая |
Внешняя разобранная общая |
Неразобранная |
|||
|
Ссылка в содержимом |
Не распознается |
Включается |
Включается при проверке |
Запрещен |
Включается |
|
|
Ссылка в значении атрибута |
Не распознается |
Включен в строку |
Запрещен |
Запрещен |
Включается |
|
|
Значение атрибута |
Не распознается |
Запрещен |
Запрещен |
Уведомление |
Не распознается |
|
|
Ссылка в значении сущности |
Включается как строка |
Пропускается |
Пропускается |
Запрещен |
Включается |
|
|
Ссылка в DTD |
Включается как сущность параметра |
Запрещен |
Запрещен |
Запрещен |
Запрещен |
Описание технологии XML Path. Место технологии в XML
Язык XPath является результатом попыток создать единые синтаксис и семантику для функционала, совместно используемого XSL Transformations [XSLT] и XPointer [XPointer]. Главная задача языка XPath - адресация частей в XML документе [XML]. Для достижения этой цели язык дополнительно наделен основными функциями для манипулирования строками, числами и булевыми значениями. В XPath используется компактный синтаксис, отличный от принятого в XML, облегчающий использование языка XPath при записи адресов URI и значений атрибутов XML. XPath работает не с внешним синтаксисом XML документа, а с его абстрактной логической структурой. XPath получил такое название потому, что использовался в URL для записи путей, обеспечивающих навигацию по иерархической структуре XML документа.
Язык XPath спроектирован так, что помимо поддержки адресации он обладает естественным набором элементов, которые могут использоваться для сравнения (проверки, соответствует ли узел некому шаблону). Такой порядок использования языка XPath описывается в спецификации XSLT.
XPath представляет XML документ в виде дерева узлов. Узлы бывают различных типов, например, узлы элементов, узлы атрибутов и узлы текста. Для каждого типа узлов в XPath определяется способ вычисления строкового значения. Некоторые типы узлов имеют также имя. XPath полностью поддерживает пространства имен XML [XML Names]. В результате, имя любого узла в этом языке образуется из двух частей: локальной части и URI некого пространства имен (возможно, нулевого), такая комбинация называется расширенным именем.
Главной синтаксической конструкцией языка XPath является выражение. Любое выражение соответствует сценарию Expr. В результате обработки выражения получается объект, относящийся к одному из четырех основных типов:
· набор узлов (node-set) - неупорядоченный набор узлов без дубликатов
· булево значение (boolean) - true или false
· число (number) - число с плавающей точкой
· строка (string) - последовательность UCS символов
Обработка выражений осуществляется, отталкиваясь от некого контекста. В спецификациях XSLT и XPointer указывается, каким образом в XSLT и XPointer, соответственно, определяется контекст для выражений XPath. Контекст образуется из:
· узла (узел контекста, context node)
· пары ненулевых положительных целых чисел (положение в контексте и размер контекста)
· привязки переменных контекста (variable bindings)
· библиотеки функций
· набора деклараций пространства имен в области видимости данного выражения
Положение в контексте всегда меньше или равно размеру контекста.
Схема привязки переменных контекста образуется в результате отображения множества имен переменных на множество значений переменных. Значением переменной является объект, относящийся к одному из типов, допустимых для значений выражений, либо к какому-либо дополнительному типу, не описанному в спецификации.
Библиотека функций образуется в результате отображения множества названий функций на множество функций. Каждая функция имеет нуль или более аргументов и возвращает один результат. В данном документе описывается основная библиотека функций, которую должны поддерживать все реализации XPath. Для любой функции в основной библиотеке и аргументы, и результат выполнения относятся к четырем основным типам. И XSLT, и XPointer дополняют XPath, определяя дополнительные функции, часть новых функций оперирует с четырьмя основными типами, остальные - дополнительными типами данных, определенными в XSLT и XPointer. Декларации пространства имен образуются в результате отображения множества префиксов на множество идентификаторов URI пространств имен.
Привязка переменных контекста, библиотека функций и декларации пространства имен используются для обработки отдельных частей выражения и остаются неизменными на протяжении обработки всего выражения. Узел контекста, размер контекста и положение в контексте, используемые для обработки частей выражения, иногда могут отличаться от используемых для обработки выражения в целом. Некоторые типы выражений меняют текущий узел контекста, однако размер контекста и положение в контексте могут менять только предикаты. Если описывается обработка некоторого типа выражений, то всегда явно указывается, когда для обработки частей выражения используется другой узел контекста, измененные размер контекста или положение в контексте. Если же об узле контекста, размере контекста или положении в контексте в описании ничего не сказано, считается, что они остаются неизменными в ходе обработки всех подвыражений в выражении указанного типа.
Выражения XPath часто используются в атрибутах XML. Описываемая в этой главе грамматика примеряется к значению атрибута после выполнения нормализации, описанной в XML 1.0. Так, если, к примеру, в грамматике используется символ <, то в исходном XML документе его нельзя записывать просто как <. Вместо этого, согласно правилам XML 1.0, его необходимо маскировать, например, записав как <. Строковые значения, используемые в выражениях, заключаются в одинарные или двойные кавычки, которые используются также для записи атрибутов XML. Поэтому, чтобы символ кавычки в этом выражении не интерпретировался XML процессором как конец значения атрибута, его необходимо записывать как ссылку на символ (" или '). Впрочем, если атрибут XML был заключен в двойные кавычки, в выражении можно свободно использовать символы одинарных кавычек, и наоборот.
Другим важным типом выражений является путь адресации (location path). Путь адресации выбирает некое множество узлов, отталкиваясь от некоторого узла контекста. Результатом обработки выражения, соответствующего пути адресации, является множество узлов, собранных согласно этому пути. Путь адресации может рекурсивно содержать выражения, используемые для фильтрации наборов узлов. Путь адресации соответствует сценарию LocationPath.
Подобные документы
Описание пакета прикладной программы Net Beans 8.1. Разработка пользовательского интерфейса апплета. Создание рамочных окон на базе фреймов библиотеки java.swing. Изменение цвета текстовых данных. Проектирование и создание инфологической модели апплета.
контрольная работа [1,8 M], добавлен 11.07.2016Описание языков программирования Java и JavaFX. Среда разработки NetBeans и класс численных методов. Архитектура и принцип работы апплета с понятным пользовательским интерфейсом. Разработка алгоритма программы на примере модели межвидовой конкуренции.
курсовая работа [1023,2 K], добавлен 19.09.2012Расширяемый язык разметки XML. Описание типа документа DTD. Значение XML и платформы Java. Обзор стандартных анализаторов DOM и SAX. Технология Java Servlet, Java Server Pages (JSP), JavaBeans. Общая функциональность программного продукта. Модель данных.
курсовая работа [422,0 K], добавлен 21.02.2009Разработка Java-апплета, имеющего возможность обращения к локальной файловой системе при предоставлении соответствующих прав доступа. Упаковка апплета в архивный JAR-файл для его подписания электронной цифровой подписью, создание ключей и сертификата.
курсовая работа [540,2 K], добавлен 08.06.2011Элементы ActiveX - результат повторной попытки фирмы Microsoft разработать модель мобильного кода. Создание документов со связыванием и внедрением объектов. Использование сертификатов Authenticode для шифрования и добавления криптографических подписей.
курсовая работа [97,5 K], добавлен 24.05.2009Разработка технологии и средств реализации Java-приложения, сокращающих трудоемкость создания и гибкость модификации интерфейса пользователя. Использование XML-документов для описания внешнего представления, элементов управления и событий экранных форм.
дипломная работа [2,8 M], добавлен 19.08.2011Разработка графического редактора для рисования двухмерной и трехмерной графики, используя язык программирования Java и интерфейсы прикладного программирования Java 2D и Java 3D. Создание графического редактора 3D Paint. Основные методы класса Graphics.
курсовая работа [197,5 K], добавлен 19.11.2009Web-дизайн, web-страница, основы строения сайта. Текстовые редакторы для разработки Web приложений. Стандартные средства разработки для Unix систем. Профессиональные среды разработки и их ответвления. Визуальные редакторы для разработчиков Web.
курсовая работа [1,4 M], добавлен 12.08.2015Описание программного обеспечения для разработки Интернет-магазина. Установка программы WYSIWYG Web Builder v3.2.0. Создание структурного макета Интернет-магазина. Проектирование главной страницы с перечнем товарных наименований (на примере TV.html).
курсовая работа [4,0 M], добавлен 30.11.2011Возможности использования Word для создания web-страницы. Использование таблицы и шаблонов оформления документа. Создание гиперссылок и закладок в Word. Обзор визуальных и текстовых редакторов для верстки веб-страниц. Веб-презентация в PowerPoint.
реферат [312,6 K], добавлен 06.04.2010
