Система и способ декларативного определения и использования подклассов внутри разметки

Изобретение относится к системе и способу декларативного определения и использования подклассов внутри документа на языке разметки. Техническим результатом является расширение функциональных возможностей. Согласно настоящему изобретению, определение подкласса пишется на основании схемы, которая может базироваться на XML. Схема содержит тег подкласса для определения имени подкласса, которое ассоциируется с типом объекта, который создается при выполнении исполняемой сборки, и одну или несколько подсказок, например, для указания языка программирования, чтобы компилировать определение подкласса; для указания суперкласса, от которого подкласс произведен; для указания действий, подлежащих выполнению, когда объект создан; для создания определения события и обработчика события для подкласса и для указания свойства, которое становится элементом в объекте, когда объект создан. 4 н. и 21 з.п. ф-лы, 10 ил.

 

Предшествующий уровень техники

В настоящее время инструментальные средства разработки программного обеспечения предоставляют разработчикам возможность создания исполнительных компонентов, используя один или несколько языков программирования как, например, С, С++, С# и подобных. Одним из преимуществ создания исполнительных компонентов является то, что однажды созданные, они могут повторно использоваться другими программами. Еще одно преимущество создания исполнительных компонентов заключается в том, что новые компоненты могут быть легко получены расширением существующих компонентов.

В общем случае компоненты расширяются посредством создания подклассов, что означает получение нового класса из существующего. Классы и подклассы пишутся с использованием одного из языков программирования. Написанный код обычно обозначается как исходный код. В традиционных средах выполнения инструментальные средства разработки программного обеспечения компилируют исходный код в объектный код и затем связывают вместе объектные коды для создания исполнительного модуля. Однако одна из проблем традиционных сред выполнения заключается в том, что для каждого языка программирования и для каждой версии языка программирования требуются различные среды выполнения.

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

Для обеих традиционной и новой сред выполнения исходный код пишется на языке программирования. У каждого языка программирования имеются собственный уникальный синтаксис и набор интерфейсов прикладного программирования (API), специфичных для конкретной среды выполнения. Для написания исходного кода разработчик программ должен изучить синтаксис языка программирования и интерфейсы прикладного программирования API, объединенные со средой выполнения. Изучение синтаксиса языка программирования и API очень трудоемко и ответственно. Кроме того, если разработчик намерен программировать, используя несколько языков программирования и/или различные среды выполнения, то он обязан помнить сходства и различия синтаксиса каждого из языков программирования и интерфейсов API для различных сред выполнения.

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

Краткое изложение сущности изобретения

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

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

Краткое описание чертежей

Фиг. 1 - пример вычислительного устройства, которое может быть использовано в пояснительных реализациях настоящего изобретения.

Фиг. 2 - функциональная блок-схема, на которой в общих чертах показаны компоненты для реализации варианта осуществления настоящего изобретения.

Фиг. 3 - функциональная блок-схема, на которой в общих чертах представлена среда выполнения для реализации некоторого варианта осуществления настоящего изобретения.

Фиг. 4-6 иллюстрируют ряд наиболее характерных фрагментов размеченных документов, на которых приведены иллюстративные примеры синтаксиса для декларативного определения подклассов согласно одному из вариантов осуществления изобретения.

Фиг. 7 - наиболее характерные фрагменты размеченного документа, на которых приведен пример синтаксиса для использования исполняемого компонента изнутри размеченного документа.

Фиг. 8 - логическая схема, на которой в общей форме проиллюстрирован процесс компиляции подклассов, определенных декларативно согласно варианту осуществления настоящего изобретения.

Фиг. 9 - логическая последовательность операций, в общих чертах иллюстрирующая процесс выполнения для использования подклассов, объявленных внутри размеченного документа согласно варианту осуществления изобретения.

Фиг. 10 - пример листинга исходного кода для представляющего исходного кода, генерируемого показанным на фиг.2 компилятором языка разметки на основании размеченных документов, приведенных на фиг. 4-6.

Подробное описание изобретения

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

Пояснительная вычислительная среда

На фиг. 1 показан пример вычислительного устройства, которое может быть использовано в пояснительных реализациях настоящего изобретения. Согласно фиг. 1, минимальная базовая конфигурация вычислительного устройства 100 обычно содержит, по меньшей мере, один обрабатывающий модуль 102 и системную память 104. В зависимости от конкретной конфигурации и типа вычислительного устройства 100 системная память 104 может быть энергозависимой (как ОЗУ), энергонезависимой (как ПЗУ, флэш-память, и пр.) или некоторой комбинацией двух упомянутых. Системная память 104 обычно содержит операционную систему 105, один или несколько программных модулей 106 и может содержать программные данные 107. Примеры программных модулей 106 представлены приложением-браузером, приложением для управления финансами, текстовым процессором и подобными приложениями. Базовая конфигурация показана на фиг. 1 в виде компонентов в пределах прерывистой линии 108.

Вычислительное устройство 100 может иметь дополнительные признаки или функциональные особенности. Например, вычислительное устройство 100 может также содержать дополнительные устройства хранения данных (сменяемые и/или несменяемые), такие как магнитные диски, оптические диски, магнитные ленты. Подобные дополнительные устройства хранения показаны на фиг. 1 как сменяемое устройство 109 и несменяемое устройство 110. Среда хранения компьютера может содержать энергозависимые и энергонезависимые, сменяемые и несменяемые среды, реализованные любым способом или технологией хранения информации, как например, считываемыми машинными инструкциями, структурами данных, программными модулями или другими данными. Системная память 104, сменяемое устройство хранения 109 и несменяемое устройство хранения 110 являются примерами сред хранения компьютера. Среда хранения компьютера содержит, не ограничиваясь приведенным ниже перечнем, память с произвольным доступом (ОЗУ), постоянную память (ПЗУ), электронную перепрограммируемую память (EEPROM), флэш-память или другую технологию хранения информации; компакт диск (CD-ROM), цифровые универсальные диски (DVD) или другое оптическое устройство хранения; магнитные кассеты, магнитную ленту, магнитный диск или другие магнитные устройства хранения или любую другую среду, используемую для хранения необходимой информации, и которая может быть доступна вычислительному устройству 100. Любая подобная среда хранения может быть частью устройства 100. Вычислительное устройство 100 может также иметь входные устройство/(устройства) 112, такие как клавиатура, мышь, перо, речевой ввод, сенсорное устройство и пр. Выходные устройства 114, такие как дисплей, речевой вывод, принтер и пр. также могут входить в состав вычислительного устройства. Эти устройства хорошо известны в данной области техники и не нуждаются в дальнейшем обсуждении.

В вычислительное устройство 100 могут также входить соединения связи 116, которые позволяют устройству 100 взаимодействовать с другими вычислительными устройствами 118, например, по сети. Соединения связи 116 - это пример коммуникационной среды. Типичными реализациями коммуникационной среды могут быть считываемые компьютером инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, как например, несущая волна или другой транспортный механизм, при этом коммуникационная среда содержит некоторую среду доставки информации. Термин "модулированный сигнал данных" означает сигнал, у которого одна или более характеристик устанавливаются или изменяются таким же образом, как при кодировании информации в сигнале. В качестве примера, а не ограничения коммуникационная среда содержит проводную среду, как например, проводную сеть или прямое проводное соединение, и беспроводную среду, как например, акустическую, радиочастотную (RF), инфракрасные и другие беспроводные среды. Упомянутый термин "считываемая компьютером среда" в данном документе означает среду, которая включает в себя среду хранения и коммуникационную среду.

Иллюстративный вариант осуществления

Фиг. 2 - функциональная блок-схема, в общих чертах иллюстрирующая систему разработки для реализации варианта осуществления настоящего изобретения. В систему входят компилятор 202 языка разметки и анализатор 204. Компилятор 202 языка разметки и анализатор 204 являются программными модулями (т.е., программными модулями 106, показанными на фиг. 1), которые могут быть резидентными в вычислительном устройстве, таком как вычислительное устройство 100, показанное на фиг. 1. Компилятор 202 языка разметки получает в качестве входных данных размеченный документ 206. В одном варианте осуществления размеченный документ 206 является документом, основанным на расширяемом языке XML разметки. Более кратко, размеченный документ 206, приведенный на фиг. 4-6 и подробно описываемый ниже, содержит теги (не показаны), которые обозначают фрагменты определения подкласса. Как будет подробно описано далее, теги обозначают присутствие подкласса и связанных элементов. По обнаружению таких тегов компилятор 202 языка разметки начинает взаимодействовать с анализатором 204 с целью построения подкласса.

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

Анализатор 204 выполнен с возможностью синтаксического разбора определений подкласса в размеченном документе 206. Более кратко, компилятор 202 языка разметки компилирует содержимое размеченного документа 206. В одном варианте осуществления компилятор 202 языка разметки преобразует это содержимое в двоичный поток маркеров (символов), который сохраняется в двоичном файле 208 с символами. Двоичный файл 208 с символами может иметь одну из нескольких форм, известных специалистам в данной области. Двоичный файл 208 с символами представляет дерево компонентов, указанных в размеченном документе 206. Однако компилятор 202 языка разметки может быть не способен преобразовывать некоторое содержимое непосредственно, и это содержимое может быть послано анализатору 204. Определения подкласса, определенные в пределах размеченного документа 206 согласно настоящему изобретению, являются примером такого содержимого. Анализатор 204 идентифицирует свойства, события и тому подобное внутри определений подкласса и передает информацию, имеющую отношение к этим элементарным единицам, компилятору 202 языка разметки.

Получив соответствующую информацию, компилятор 202 языка разметки добавляет те символы в размеченный документ 206, которые связаны с определением подкласса. Компилятор 202 языка разметки может также генерировать представляющий исходный код 212, по которому создаются сборки 210 на промежуточном языке ПЯ. ПЯ сборки 210 включают в себя машинные инструкции для подклассов (например, компонентов), определенных в размеченном документе 206. Ранее такие ПЯ сборки 210 генерировались с использованием инструментальных средств разработки программного обеспечения, которые компилировали и связывали исходный код, написанный на языке программирования. В другом приводимом варианте осуществления специалист в данной области оценит также то, что компилятор 202 языка разметки способен генерировать ПЯ сборки 210 без генерации двоичного файла 208 с символами (маркерами).

ПЯ сборки 210, созданные компилятором 202 языка разметки, могут быть повторно используемы другими традиционными инструментальными средствами разработки программ. В дополнение, ПЯ сборки 210 могут быть повторно используемы в других размеченных документах. Возможность повторного использования ПЯ сборок 210 внутри документа на языке разметки показана на фиг. 7 и описана в настоящем документе. Таким образом, настоящее изобретение предоставляет разработчикам компонентов возможность легкого построения и расширения компонентов, используя язык разметки. Если новые компоненты были построены согласно настоящему изобретению, то новые компоненты появляются так, как если бы они были созданы с использованием традиционного языка программирования. Таким образом, разработчики, применяющие механизм и способ настоящего изобретения, могут строить компоненты без изучения синтаксиса и нюансов одного или нескольких языков программирования.

На фиг. 3 приведена функциональная блок-схема, которая в общих чертах представляет среду выполнения для реализации одного варианта осуществления настоящего изобретения. Среда выполнения содержит (вычислительную) машину 302 выполнения, двоичный считыватель 304 символов и двоичный загрузчик 306 символов. Когда машина 302 выполнения принимает запрос на загрузку конкретного ресурса (например, документа 206 на языке разметки, показанного на фиг. 2), машина 302 выполнения осуществляет доступ к таблице 308 отображения страницы. Таблица 308 отображения страницы идентифицирует, имеет ли размеченный документ 206 откомпилированную версию (например, двоичный файл 208 символов) или не имеет. Если откомпилированная версия существует, то машина 302 выполнения взаимодействует с двоичным загрузчиком 306 символов с целью загрузки двоичного файла 208 с символами. В одном варианте осуществления двоичный файл 208 с символами идентифицирует ПЯ сборки (например, ПЯ сборки 210), связанные с двоичным файлом 208 с символами. Затем двоичный загрузчик 306 символов загружает идентифицированные ПЯ сборки 210. Как только фрагмент файла или весь двоичный файл 208 с символами и связанные с ним ПЯ сборки 210 будут загружены, двоичный считыватель 304 символов начинает читать двоичный файл 208 с символами и ПЯ сборки 210, чтобы сгенерировать инструкции на языке процессора, которые исполняются процессором (например, процессорным модулем 102, показанным на фиг. 1). Двоичный считыватель 304 символов может получать доступ к метаданным 310 для обнаружения информации, например, о типах, методах и событиях. В общем случае метаданные 310 содержат информацию о методах, полях, свойствах и событиях. Каждая из этих элементарных составляющих может иметь собственные метаданные, которые могут считываться для получения дополнительных подробностей. Таким образом, используя метаданные 310, двоичный считыватель 304 символов во время выполнения использует отображение, чтобы программно обнаруживать информацию об элементах двоичного файла 208 с символами (маркерами). В дополнение, как будет подробнее описано далее, подклассы, первоначально определенные в размеченном документе 206, могут исполняться непосредственно, используя ПЯ сборки 210, созданные согласно настоящему изобретению.

На фиг. 4-6 показан ряд наиболее характерных фрагментов разметки в документе 206 на языке разметки, которые иллюстрируют пример синтаксиса для определения подклассов декларативно согласно одному из вариантов осуществления настоящего изобретения. На фиг. 10 приведен пример листинга исходного кода, иллюстрирующего представляющий исходный код, который может генерировать компилятор 202 языка разметки по упомянутым характерным фрагментам разметки, показанным на фиг. 4-6. В одном варианте осуществления компилятор 202 языка разметки действительно способен генерировать файл, который содержит представляющий исходный код. Это может происходить, когда разработчик установил флаг отладки. Файл, который содержит представляющий исходный код, затем позволяет разработчику выявлять возможные проблемы в тексте документа 206 на языке разметки или проблемы, связанные с компилятором 202 языка разметки. В другом варианте осуществления представляющий исходный код может не сохраняться внутри файла. Для такого варианта осуществления компилятор 202 языка разметки может генерировать двоичный файл 208 с символами и ПЯ сборки 210 с предварительной генерацией представляющего исходного кода или без первоначальной генерации представляющего исходного кода.

Обобщенно в серии чертежей фиг. 4-6 последовательно описываются различные аспекты для декларативного определения подкласса внутри разметки согласно настоящему изобретению. На фиг. 4 приведен иллюстративный пример синтаксиса для определения подкласса и иерархии подкласса. На фиг. 5 показан иллюстративный пример синтаксиса для определения идентификаторов, кода и конструкторов подкласса. На фиг. 6 приведен иллюстративный пример синтаксиса для определения свойств и событий подкласса. Каждая из фигур чертежей далее будет описана подробно.

На фиг. 4 приведен иллюстративный пример синтаксиса для определения подкласса и иерархии подкласса. Характерный фрагмент разметки 400 (т.е., определение подкласса) включает в себя тег 402 суперкласса (например, "Button"). Для последующего описания каждый тег (например, тег 402 суперкласса) имеет соответствующий закрывающий тег. Для удобства в приведенном описании на закрывающий тег явных ссылок нет, но этот тег показан на соответствующих чертежах. Разметка 400 включает в себя атрибут 404 пространства имен, объявление 406 определения пространства имен и несколько подсказок компилятору (например, подсказки 408 и 410). Атрибут 404 пространства имен идентифицирует конкретное пространство имен (например, "System.Control") и сборку, в которой находится суперкласс (например, Button). Объявление 406 определения пространства имен показывает, что любой атрибут внутри разметки 400, который содержит префикс "def:", представляет собой подсказку компилятору в зависимости от тех действий, которые компилятор должен осуществить.

Например, подсказка 408 (здесь и далее упоминаемая как подсказка 408 языка) требует от компилятора сгенерировать ПЯ сборки с использованием конкретного языка (например, C#), назначенного подсказке 408 языка. Подсказка 408 языка может иметь один из произвольного количества назначаемых языков программирования, таких как С, С++ и подобных. Подсказка 410 (здесь и далее упоминаемая как подсказка 410 класса def:Class) требует от компилятора определять подкласс, используя имя 414 (например, MyButton), назначенное подсказке 410 класса def:Class. Подсказка 410 класса def:Class может также содержать пространство 412 имен подкласса, которое идентифицирует пространство имен (например, MyControlLib), с которым следует связывать новый подкласс. Таким образом, согласно фиг. 4 разработчик имеет определенный декларативно новый подкласс, именованный "MyButton", который расширяет класс "Button", находящийся в пространстве имен "System.Controls". Новый подкласс будет связан с пространством имен "MyControlLib".

В разметке 400, показанной на фиг. 4, определен тег 420 объявления элемента (например, "Image"). Поскольку внутри тега 420 объявления элемента не определено специальное пространство имен, то атрибут 404 пространства имен определяет также и местоположение того элемента (например, "Image"), который связан с тегом 420 объявления элемента. Тег 420 объявления элемента содержит элемент 421 и атрибут источника 422. Атрибут источника 422 содержит свойство 424 (например, "Source") и значение 426 (например, "HappyFace.jpg"). Поскольку для подкласса, определенного как "MyButton", тег 420 объявления элемента находится внутри определения подкласса, то элементам, связанным с тегом 420 объявления элемента, будут приписаны значения при приписывании значений объектам подкласса. В дополнение, элементы, связанные с тегом 420 объявления элемента, содержатся внутри коллекции дочерних элементов нового подкласса. Другими словами, данный подкласс является родительским для элементов, связанных с тегом 420 объявления элемента. Таким образом, специалист в данной области оценит то, что разметка 400 дает возможность разработчикам выразить иерархию в той форме, которая позволяет компилятору генерировать деревья элементов, корни которых обращены к определяемым подклассам (например, MyButton).

На фиг. 5 приведен пример синтаксиса для определения идентификаторов, кода и конструкторов подкласса. Характерный фрагмент разметки 500 включает в себя описанную выше разметку 400 в дополнение к разметке для определения идентификаторов, кода и конструкторов. Для удобства ссылочные позиции, приведенные на фиг. 4 и описанные выше, не показываются на фиг. 5, если только они не являются полезными при описании новых аспектов. На фиг. 5 тег 420 объявления элемента дополнительно содержит атрибуты, такие как атрибут 520 идентификатора и атрибут 526 события. Атрибут 520 идентификатора содержит свойство 521 идентификатора (например, "ID") и значение 523 идентификатора (например, "img1"). Атрибут 520 идентификатора иллюстрирует пример механизма для определения идентификаторов подкласса согласно настоящему изобретению.

Атрибут 526 события содержит триггер 527 события (например, "DataLoaded") и значение 529 события (например, функцию "OnLoaded"). Триггер 527 события указывает контролируемое событие, и значение 529 события указывает тот метод, который выполняется при установке триггера 527 события. Значение 529 события связано с методом 530 (например, "OnLoaded"). Метод 530 может быть написан на языке программирования. Метод 530 может обращаться к экземплярам класса и подкласса, определенным внутри разметки 500. Когда метод 530 написан с использованием языка программирования внутри размеченного документа, то метод 530 связывается с подсказкой 540 кода. Подсказка 540 кода дает возможность разработчикам добавлять участки кода к телу определения подкласса. В одном варианте осуществления такой код следует за подсказкой 540 кода и является вызываемым методом или обработчиком события. Например, внутри разметки 500 функция 530 OnLoaded служит обработчиком события для события DataLoad, которое возбуждается элементом управления Image. Другие участки кода также могут добавляться к телу определения подкласса, как например, функция 550 CustomInit, показанная на фиг. 5.

Разметка 500 содержит также подсказку 542 конструктора. Подсказка 542 конструктора дает возможность разработчику писать дополнительный конструктор, который дополняет конструктор по умолчанию, создаваемый для подкласса. В одном варианте осуществления дополнительный конструктор задает то последнее поведение, которое выполняется сгенерированным конструктором по умолчанию. Дополнительный конструктор может также содержать код, который воздействует на поведение подкласса во время работы конструктора. Разработчик может вызвать конструктор суперкласса внутри дополнительного конструктора. Дополнительный конструктор, показанный на фиг. 5, вызывает функцию 550 CustomInit, которая является закрытым методом, определенным пользователем.

На фиг. 6 приведен иллюстративный пример синтаксиса для определения свойств и событий подкласса. Характерный фрагмент разметки 600 в дополнение к разметке для определения свойств и событий подкласса содержит описанные выше разметки 400 и 500. Для чтения ссылочные позиции, приведенные на фиг. 4-5 и описанные выше, не показываются на фиг. 6, если только они не являются полезными при описании новых аспектов.

Разметка 600 содержит подсказку 610 свойств, которая дает возможность определения свойств подкласса. Свойство ведет себя как переменная-член подкласса. Подсказка 610 свойств может содержать один или несколько атрибутов, таких как атрибут 612 имени, атрибут 614 типа, атрибут 616 значения по умолчанию и атрибут 618 флага. Атрибут 612 имени указывает имя свойства. В одном варианте осуществления имена учитывают регистр и (вычислительная) машина выполнения не устанавливает ограничения на те символы, которые используются для имен. Имя должно быть уникальным для владельца, который регистрирует это имя. Атрибут 614 типа указывает тип значения свойства. Такими типами могут быть встроенные типы (intrinsic), определенные пользователем (user-defined), структуры (struct), классы (class), интерфейсы (interface), перечисления (enum) и подобные им. Атрибут 616 значения по умолчанию указывает значение, которое будет присвоено свойству при приписывании значений. Атрибут 618 флага указывает тип методов, которые создаются оболочкой при приписывании значений свойства. Флаги могут иметь способность управления характеристиками свойства, как например, ТолькоЧтение (ReadOnly), Наследуемый для дочерних элементов (Inheritable), Закрытый (Private) и им подобными.

Разметка 600 содержит также подсказку 620 события. Подсказка 620 события дает возможность определения событий класса. Подсказка 620 события может содержать атрибуты такие как атрибут 622 имени, атрибут 624 маршрута, атрибут 626 флага и им подобные. Атрибут 622 имени указывает строку, которая служит ссылкой на это событие. Когда xml файл использует подкласс, то xml файл использует строку для присоединения необходимого прикладного кода, определенного разработчиком. Атрибут 624 маршрута указывает метод, который задает те элементы дерева, для которых устанавливается данное событие. Атрибут 626 флага события указывает другие характеристики, связанные с событием. Например, для разметки 600 компилятор языка разметки будет генерировать код для разрешения события, именованного "DblClk", и информацию, связанную с событием, такую как поддерживаемая маршрутизация, флаги и подобную. Специалист в данной области оценит то, что имена и значения, связанные с атрибутами, могут быть изменены без выхода за объем настоящего изобретения.

Разметка 600 содержит также объявление 630 обработчика события. Объявление 630 обработчика события может иметь связанные с обработчиком события модификаторы 632 такие как открытый/закрытый (public/private), делегировать (delegate), возвращаемый тип (return type) и им подобные. На фиг. 6 объявление 630 обработчика события задает обработчик события (т.е., метод) (например, "DblClckEventHandler"), который вызывается при наступлении события.

В размеченном документе могут быть определены также и другие теги. Например, тег корня (например, "def:Library") может быть использован для информирования компилятора и/или анализатора о том, что следует поместить определение подкласса в отдельный файл или поместить определение подкласса в один файл вместе с другими подклассами и подобное этому. Пространство имен может объявляться для созданного пользователем элемента для всех классов, определенных внутри корневого тега, и подобно этому.

На фиг. 7 приведены характерные фрагменты размеченного документа, который иллюстрирует пример синтаксиса для использования подкласса внутри размеченного документа. Разметка 700 содержит корневой элемент 702 (например, элемент FlowPanel), объявление 704 пространства имен по умолчанию, префикса 706 пространства имен определения и элемент 708. Будет оценено то, что элемент 708 может обращаться к созданному пользователем компоненту, который был построен с использованием указанного выше синтаксиса. Объявление 704 пространства имен по умолчанию указывает пространство имен по умолчанию для тегов без префиксов. В иллюстративной разметке 700 объявление 704 пространства имен по умолчанию ссылается на пространство имен "SystemControls". Префикс 706 пространства имен определения указывает местоположение, где может быть найден созданный пользователем компонент или элемент. В иллюстративной разметке 700 префикс 706 пространства имен определения ссылается на "MyControlLib". Элемент 708 включает в себя имя 710 класса (например, "MyControlLib"), идентификатор 712 и текстовую строку 714. Имя 710 класса ссылается на тот класс, который создается для данного элемента. Идентификатор 712 служит ссылкой на элемент и содержит имя (например, "ID") и значение (например, "button1"). Данное значение во время выполнения становится именем экземпляра имени 710 класса (например, button1).

Обобщенная схема работы иллюстративной реализации

На фиг. 8 показана логическая диаграмма, которая в общих чертах иллюстрирует процесс 800 компиляции подкласса, определенного декларативно согласно одному из вариантов осуществления настоящего изобретения. Пример разметки, показанный на фиг. 4-6, вместе с представляющим исходным кодом на фиг. 10 используются в сочетании с фиг. 8 для описания процесса 800. После сравнения фиг. 10 с разметкой 600 без особого труда можно признать, что настоящее изобретение позволяет генерировать сложные подклассы декларативно, не требуя от разработчика понимания языка программирования. Представляющий код на фиг. 10 является исходным кодом языка C#. Однако компилятор языка разметки согласно настоящему изобретению может генерировать представляющий код, используя синтаксис любого языка программирования.

Процесс 800 начинается с этапа 801, где компилятор языка разметки компилирует размеченный документ и встречает разметку, содержащую определение подкласса. Компилятор языка разметки может установить, что ему встретилось определение подкласса посредством любого механизма, как например, не распознание разметки как какого-либо формата, распознавание тега подкласса (например, def:Class) и подобного. Например, в разметке 400 компилятор языка разметки может обработать несколько предложений прежде, чем встретится тег подкласса (например, подсказка 410 def:Class), который идентифицирует определение подкласса. В других вариантах осуществления тег подкласса может встретиться перед остальными предложениями, как например, в том случае, когда подкласс не специфицирует базовый класс (например, button). В общем случае тег подкласса может появиться там, где допускается появление тега элемента внутри разметки. Если разметка идентифицирована как содержащая определение подкласса, то процесс продолжается с этапа 802.

Тег подкласса обрабатывается на этапе 802. Как было описано при ссылке на фиг. 4, тегу подкласса (упоминаемому также как подсказка 410 класса def:Class) назначено имя 414, которое может также содержать пространство 412 имен подкласса. На основании этой информации для сборки может быть сгенерирован представляющий код такой, как на строке 1 фиг. 10. В дополнение генерируется класс, имеющий назначенное имя, как показано на строке 5 фиг. 10. Строка 5 будет наращиваться другим сгенерированным кодом после обработки дополнительных предложений (например, для пространства имен и суперкласса). Как часть обработки тега подкласса процесс устанавливает, расширяется ли подкласс из какого-либо класса (например, суперкласс), и получает информацию, связанную с суперклассом. Согласно фиг. 4 создаваемый класс "MyButton" расширяет класс "Button", как определено тегом 402 суперкласса. Таким образом, на строке 5 фиг. 10 показан представляющий код, иллюстрирующий расширение MyButton из Button.

В дополнение для подкласса генерируется конструктор по умолчанию. И в этом случае по мере обработки дополнительных предложений конструктор по умолчанию может наращиваться дополнительным представляющим кодом. Строки 23-24 и 26 на фиг. 10 соответствуют генерируемому представляющему коду. Однако, "this._Initialize_This()" является кодом, который, как будет показано ниже, добавляется после обработки очередного предложения. После обработки тега подкласса обработка продолжается на этапе 804.

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

На этапе 806 принятия решений устанавливается, определяет ли данное предложение класс. Как отмечалось выше, настоящее изобретение дает возможность выразить иерархию декларативно. В экземпляре варианта осуществления предложение, определяющее другой класс (т.е., элемент), являющийся дочерним для подкласса, появится после предложения тега подкласса. В предположении, что на данный момент текущее предложение не определяет некоторый подкласс, обработка продолжается на этапе 808.

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

На этапе 810 принятия решений проверяется, остались ли для данного определения подкласса предложения, подлежащие обработке. Если есть другое предложение, обработка в цикле возвращается к этапам 804-808, и происходит обработка этого предложения. Как только все предложения внутри подкласса обработаны, процесс обработки переходит от этапа 810 принятия решений к этапу 812.

На этапе 812 осуществляется генерация ПЯ сборок для данного определения подкласса с использованием представляющего кода, сгенерированного в течение указанного выше процесса. Разработчик, возможно, задал в одном из предложений подсказок компилятору (этап 820) язык программирования для использования при генерации представляющего кода; может иметь место определение, какой файл сборки используется для сохранения определения подкласса и тому подобное. После того, как сгенерированы ПЯ сборка или ПЯ сборки, обработка завершена. Как отмечалось выше, созданная сборка теперь готова быть исполнимой с применением традиционных языков программирования, с применением предложений разметки согласно настоящему изобретению и с применением других подобных средств. Сборка появляется, как если бы была написана на языке программирования.

Возвращаясь к этапу 806 принятия решений: в том случае, если предложение начинает определение нового класса (т.е., элемента), обработка продолжается в этапе 814. На этапе 814 предложения, принадлежащие к новому классу, обрабатываются на этапе 808, где обрабатывается каждое из предложений до тех пор, пока не будут обработаны все предложения, принадлежащие к новому классу. Например, на фиг. 5 предложения 520, 526, 422 обрабатываются для нового класса "Image". Image является потомком подкласса "MyButton". Обработка продолжается на этапе 804, где продолжают обрабатываться предложения, связанные с подклассом.

Теперь вернемся к этапу 808: ниже описывается обработка для каждого индивидуального типа предложения (этапы 820-832), которые могут появиться внутри определения подкласса. На этапе 820 обрабатываются предложения, служащие подсказками компилятору. В общем случае предложения, которые являются подсказками компилятору, обеспечивают информацию для компилятора языка разметки о том, как следует генерировать сборку. Например, согласно фиг. 4 подсказка 408 языка является предложением подсказки компилятору языка разметки. Предложение информирует компилятор языка разметки о том, какой язык программирования необходимо использовать при генерации представляющего кода. На фиг. 4 подсказке 408 языка назначен C#, таким образом, представляющий код, показанный на фиг. 10, является исходным кодом C#.

На этапе 822 обрабатываются предложения, которые определяют пространства имен. Эти пространства имен затем включаются в состав представляющего кода, как показано в строках 2 и 3 на фиг. 10.

На этапе 824 обрабатываются предложения, которые определяют идентификатор (id) класса. Для каждого из атрибутов идентификатора внутри размеченного документа компилятор языка разметки генерирует элемент поля для соответствующего класса. Элемент поля генерируется с тем же типом, что и у класса, для которого определен данный атрибут идентификатора. Именем элемента поля является значение идентификатора (id), присвоенное атрибуту идентификатора (id). Например, согласно фиг. 5 при обработке предложений, относящихся к классу Image, встречается атрибут 520 идентификатора (id). Таким образом, как показано на строке 7 фиг. 10 компилятор языка разметки будет генерировать представляющий код для класса MyButton, который имеет элемент поля, определенный как private System.Controls.Image img1.

Во время выполнения элемент поля инициализируется как экземпляр соответствующего типа (например, Image), который создается методом InitComponent(). В результате любой код в классе MyButton может получить доступ к любому другому экземпляру элемента в его иерархии просто по значению идентификатора (id) этого класса. Инициализация элемента поля показана на строке 37 фиг. 10.

На этапе 826 обрабатываются предложения, которые определяют свойство класса. Для всех свойств, определенных внутри размеченного документа компилятор языка разметки генерирует представляющий исходный код для свойства и при необходимости регистрирует свойство. Например, согласно фиг. 6 разметка 600 содержит подсказку 610 свойств, которая имеет различные атрибуты 612-618. Подсказка 610 свойств будет информировать компилятор языка разметки о том, что предложения, следующие за подсказкой 610 свойств, предназначены для свойства. Затем читаются атрибуты 612-618 как предложения свойств. Компилятор языка разметки будет генерировать представляющий код для свойства "Label", чтобы зарегистрировать это свойство для класса MyButton так, как показано в строках 9-12 на фиг. 10. Компилятор языка разметки будет также генерировать представляющий код для определения свойства, как показано в строках 28-30 на фиг. 10. Строки 28-30 иллюстрируют то, как атрибут 612 имени становится именем свойства в представляющем коде и атрибут 614 типа становится типом свойства в представляющем коде.

В одном варианте осуществления процесс генерирует код для значений свойства, вызывая объект TypeConverter для конкретного типа этого свойства, при этом объект TypeConverter исполняет код непосредственно во время выполнения, используя отображение и преобразуя заданную строку в экземпляр реального объекта, соответствующего свойству по типу. В другом варианте осуществления процесс 800 вызывает преобразователь типа для данного свойства, чтобы получить значение реального объекта, и преобразует это значение в объект InstanceDescriptor. Объект InstsnceDescriptor содержит достаточную информацию, так что компилятор языка разметки может отобразить ее на объект, чтобы генерировать представляющий код, который создает новый экземпляр для типа полученного значения в соответствии с атрибутами подсказки свойств. Строками 28-30 на фиг. 19 показывается то, как labelProperty будет устанавливаться во время приписывания значений для экземпляра MyButton во время выполнения по значению, присвоенному свойству Label. Присваиваемое значение может быть указано декларативно в разметке (как показано на фиг. 7) или присвоено программно с использованием какого-либо языка программирования.

На этапе 828 обрабатываются предложения, которые определяют событие класса. Для предложений события компилятор языка разметки генерирует представляющий код для события. События могут быть определены в разметке с применением различных механизмов, как например, атрибут 526 события, показанный на фиг. 5, или как подсказка 620 события, показанного на фиг. 6. Первым описывается механизм, использующий атрибут события. Атрибут события содержит триггер события и значение события. Триггер события соответствует событию, и значение события соответствует методу, который исполняется, когда осуществляется установка триггера события. Согласно фиг. 5, значение 529 события ("OnLoaded") добавляется к обработчику события, что показано на строках 38-40 представляющего кода на фиг. 10 посредством определения "this.OnLoaded" как нового System.Controls.DataLoadedEventHandler. Триггер 527 события ("DataLoaded") добавляется как событие в строке 38 представляющего кода на фиг. 10 посредством определения первого параметра метода AddHandler как System.Controls.Image.DataLoadedEvent. Другие параметры AddHandler могут использовать значения по умолчанию или могут быть указаны в размеченном документе.

Теперь описывается механизм подсказки 620 события. Подсказка 620 события содержит атрибут имени события и другие атрибуты. Имя, присвоенное атрибуту имени события, регистрируется как событие. Например, согласно фиг. 6, "DblClick" является именем, присвоенным атрибуту имени события. Таким образом, "DblClick" есть первый параметр метода RegisterEvent согласно фиг. 10, генерация которого приведена в строках 14-16 на фиг. 10. Тип объявления 630 обработчика события для метода DblClickEventHdlr также служит параметром метода RegisterEvent согласно фиг.10. И в этом случае другие параметры метода RegisterEvent могут использовать значения по умолчанию или могут быть указаны в размеченном документе, используя другие атрибуты. Во время выполнения согласно настоящему изобретению событие подключается с использованием отражения для того, чтобы идентифицировать тип обработчика DblClckEventHandler и найти местонахождение метода. В другом варианте осуществления событие подключается так, что отражение не является необходимым, как описано в одновременно рассматриваемой патентной заявке №10/377, 196, «System and Method for Creating a Routine Connection Interface for Attributes and Element Tags Defined within d Page Subclass in a Markup Document", права на которую переданы обычным образом, поданную 28 февраля 2003, которая включена в настоящее описание по ссылке.

На этапе 830 обрабатываются предложения, которые определяют код. Предложения, которые определяют код, следуют за предложением (этап 820) подсказки компилятору, как например, за предложением для подсказки кода. Данные предложения написаны на языке программирования и будут появляться в таком же виде, как и в представляющем коде. Например, на фиг.5 проиллюстрирован метод 530 и функция 550 CustomInit. Метод 530 и функция 550 CustomInit показываются, соответственно, в строках 18-19 и 21 на фиг.10.

На этапе 832 обрабатываются предложения, которые определяют дополнительный конструктор. И в этом случае предложения, которые определяют дополнительный конструктор, следуют за предложением (этап 820) подсказки компилятору, как например, за предложением для подсказки конструктора. Компилятор языка разметки генерирует дополнительный конструктор ("this._Initialize._This()" согласно фиг.10) и добавляет предложения с дополнительным конструктором. Например, согласно фиг.5 предложение после подсказки 542 конструктора вызывает "CustmInit()". Таким образом, согласно фиг.10 в строке 33 компилятор языка разметки добавляет "CustmInit()" к дополнительному конструктору в представляющем коде.

Специалисты в данной области оценят, что этап 812 может быть выполнен с приращениями в течение обработки на этапах 804-810 без отрыва от настоящего изобретения. Как дополнение, в зависимости от функциональной реализации анализатора 204 и компилятора 202 языка разметки во время процесса 800 могут иметь место функции обратного вызова между анализатором 204 и компилятором 202 языка разметки.

Фиг.9 является логической диаграммой, которая в общих чертах иллюстрирует процесс 900 выполнения для использования подклассов, объявленных в размеченном документе согласно варианту осуществления настоящего изобретения. Иллюстративный пример разметки, показанный на фиг.7, используется в сочетании с фиг.9 для описания процесса 900. Процесс 900 начинается на этапе 901, где (вычислительная) машина выполнения принимает запрос на конкретный ресурс (например, на размеченный документ) и устанавливает, что для ресурса существует откомпилированная версия. Например, обратимся к фиг.7, и предполагая, что разметка 700 еще не была предварительно скомпилирована в двоичный файл с символами (маркерами), когда компилятор языка разметки встретил элемент 708, компилятор языка разметки установит, что класс MyButton имеет связанные с ним двоичный файл с символами и ПЯ сборку. Этот ассоциированный двоичный Файл с символами, который содержит атрибуты символов для класса MyButton, будет далее обрабатываться процессом 900. Ассоциированный двоичный файл с символами и ПЯ сборка могли быть сгенерированы с использованием настоящего изобретения. Обработка продолжается на этапе 902.

На этапе 902 загружается двоичный файл с символами (маркерами). Двоичный файл с символами может быть загружен с приращениями или полностью. Двоичный файл с символами может идентифицировать те ПЯ сборки, связанные с двоичным файлом с символами, которые требуют загрузки. Если для примера обратиться к фиг.7, то загружаются ПЯ сборки, связанные с классом MyButton. Обработка продолжается на этапе 904.

На этапе 904 осуществляется запрос символа из двоичного файла с символами. Как отмечалось выше, в новой среде выполнения генерируемый двоичный файл с символами не зависит от языка программирования, который был использован для генерации двоичного файла с символами (маркерами). Таким образом, машина выполнения может обрабатывать двоичный файл с символами, не обращаясь к языку программирования, который был первоначально применен для создания двоичного файла с символами. Обработка продолжается на этапе 906 принятия решений.

На этапе 906 принятия решений устанавливается, является ли найденный символ событием. Если символ (маркер) не соответствует событию, обработка продолжается на этапе 908.

На этапе 908 обрабатывается символ (маркер, метка). Как отмечалось выше, обработка символа (маркера, метки) не зависит от того способа, посредством которого генерируется двоичный файл с символами. Другими словами, обработка символов из созданного декларативно согласно размеченному документу двоичного файла с символами, или символов из файла символов, полученного с применением языка программирования, будет происходить одинаковым образом. Следовательно, поскольку обработка символов в двоичном файле с символами хорошо известна специалистам в данной области, то обработка символа (метки) не требует дальнейшего обсуждения. Обработка продолжается на этапе 910 принятия решений.

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

Теперь вернемся на этап 906 принятия решений: если символ является событием, обработка продолжается на этапе 912. На этапе 912 загружаются метаданные, связанные с двоичным файлом с символами. Метаданные содержат описания типов, ресурсов, методов и тому подобное. Обработка продолжается на этапе 914.

На этапе 914 на основании метаданных и отображения процесс находит тип целевого элемента для данного события. Это требует доступа к метаданным и прослеживания всех полей для определения типа. Обработка продолжается на этапе 916.

На этапе 916 проверятся событие для типа целевого элемента. Это гарантирует, что событие будет действительным событием. Если событие не является действительным для типа целевого элемента, то это приводит к ошибке. Обработка продолжается на этапе 918.

На этапе 918 используется отображение на тип целевого элемента для получения того метода события, который затем исполняется. Исполнение метода события вовлекает исполнительный код внутри объединенной ПЯ сборки. Таким образом, обращаясь к фиг.7: как только произойдет приписывание значения объекту MyButton, и событие будет найдено, присоединяется метод этого события ("DblClickEvent"). Это влечет присоединение обработчика события (например, DblClickEventHandler) к событию (например, DblClickEvent). Обработка продолжается на этапе 910 принятия решений и происходит так, как описано выше.

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

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

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

2. Считываемый компьютером носитель по п.1, в котором идентификация определения подкласса содержит синтаксический анализ тега подкласса, причем тег подкласса содержит атрибут имени подкласса для определения имени, связываемого с типом объекта, который становится созданным.

3. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса включает в себя компиляцию определения подкласса в представляющий исходный код, который компилируется в сборку.

4. Считываемый компьютером носитель по п.3, в котором представляющий исходный код основан на языке программирования.

5. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса включает в себя компиляцию кода внутри определения подкласса в сборку, при этом код описывается внутри определения подкласса посредством указания кода.

6. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса содержит синтаксический анализ тега суперкласса, который определяет суперкласс, от которого произведен подкласс, указание наследования с использованием синтаксиса, связанного с упомянутым языком программирования, и компиляцию синтаксиса, чтобы стать частью сборки.

7. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания конструктора, который определяет по меньшей мере одно дополнительное действие, которое выполняется при создании объекта, при этом дополнительное действие является частью сборки.

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

9. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания свойства, которое определяет свойство подкласса, которое становится элементом в объекте при создании объекта.

10. Считываемый компьютером носитель по п.1, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ тега объявления элемента, который идентифицирует дочерний элемент подкласса.

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

12. Способ по п.11, в котором идентификация определения подкласса включает в себя синтаксический анализ тега подкласса, причем тег подкласса содержит атрибут имени подкласса для определения имени, связываемого с типом объекта, который становится созданным.

13. Способ по п.11, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ тега суперкласса, который определяет суперкласс, от которого произведен подкласс, указание наследования с использованием синтаксиса на основе языка программирования и компиляцию синтаксиса, чтобы стать частью сборки.

14. Способ по п.11, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания конструктора, которое определяет по меньшей мере одно дополнительное действие, которое выполняется при создании объекта, при этом дополнительное действие является частью сборки.

15. Способ по п.11, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания события, которое создает определение события и соответствующий обработчик события для этого подкласса.

16. Способ по п.11, в котором генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания свойства, которое определяет свойство подкласса, которое становится элементом в объекте при создании объекта.

17. Компьютерная система для генерации сборки из определения подкласса внутри документа на языке разметки, при этом компьютерная система содержит

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

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

18. Компьютерная система по п.17, в которой идентификация определения подкласса включает в себя синтаксический анализ тега подкласса, причем тег подкласса содержит атрибут имени подкласса для определения имени, связываемого с типом объекта, который становится созданным.

19. Компьютерная система по п.17, в которой генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания конструктора, которое определяет по меньшей мере одно дополнительное действие, выполняемое при создании объекта, причем дополнительное действие является частью сборки.

20. Компьютерная система по п.17, в которой генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания события, которое создает определение события и соответствующий обработчик события для подкласса.

21. Компьютерная система по п.17, в которой генерация сборки на основании определения подкласса включает в себя синтаксический анализ указания свойства, которое определяет свойство подкласса, которое становится элементом в объекте при создании объекта.

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

23. Система по п.22, в которой средство для идентификации определения подкласса включает в себя средство для синтаксического анализа тега подкласса, причем тег подкласса включает в себя атрибут имени подкласса для определения имени, связываемого с типом объекта, который становится созданным.

24. Система по п.22, в котором средство для генерации сборки на основании определения подкласса включает в себя средство для синтаксического анализа тега суперкласса, который определяет суперкласс, от которого произведен подкласс, средство для указания наследования с использованием синтаксиса на основании языка программирования и средство для компиляции синтаксиса, чтобы стать частью сборки.

25. Система по п.22, в котором средство для генерации сборки на основании определения подкласса содержит средство для синтаксического анализа указания конструктора, которое определяет по меньшей мере одно дополнительное действие, которое выполняется при создании объекта, при этом дополнительное действие является частью сборки.