ИСПОЛЬЗОВАНИЕ МЕХАНИЗМА ПРИВЯЗКИ ДАННЫХ ДЛЯ ВЫПОЛНЕНИЯ ПРИВЯЗКИ КОМАНД Российский патент 2010 года по МПК G06F9/44 

Перекрестные ссылки на связанные заявки

Настоящая заявка связана с заявкой на патент, идентифицируемой номером дела поверенного MSFT-3489/307340.1, озаглавленной «Привязка приоритета», поданной согласно настоящему документу.

Область техники

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

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

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

В типовом случае художник компьютерной графики проектирует внешний вид пользовательского интерфейса, в то время как разработчик программы пишет код, который реализует пользовательский интерфейс и/или лежащую в его основе (базовую) модель. Проектирование компьютерной графики и разработка программного обеспечения представляют собой две весьма различающиеся дисциплины, поэтому художникам компьютерной графики и разработчикам программ часто бывает трудно работать продуктивно вместе. В типовом случае художник компьютерной графики использует инструментальные средства компьютерной графики, такие как Adobe® Photoshop® и Adobe® Illustrator® для создания макета пользовательского интерфейса (ПИ), и затем разработчик программы воссоздает ПИ в коде. Элементы исходного проекта компьютерной графики в типовом случае повторно не используются в конечной реализации, и иногда части проекта теряются в процессе, поскольку разработчик либо не может без труда воссоздать проект компьютерной графики в коде, либо не полностью понимает упомянутый проект компьютерной графики. Если проект компьютерной графики модифицирован, то художнику компьютерной графики может потребоваться повторно спроектировать ПИ, а разработчику программы - переписать части кода, чтобы согласовать их с проектом компьютерной графики. Короче говоря, процесс является громоздким.

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

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

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

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

Сущность изобретения

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

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

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

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

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

Фиг.3 - более детальная блок-схема фиг.2, соответствующая варианту осуществления изобретения;

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

Фиг.5 - блок-схема приведенного для примера способа привязки команд в соответствии с вариантом осуществления изобретения;

Фиг.6 - диаграмма объектов в соответствии с аспектом изобретения.

Детальное описание приведенных для примера вариантов осуществления изобретения

Обзор

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

Пример вычислительной среды

Фиг.1 и последующее описание предназначены для обеспечения краткого обобщенного описания подходящей вычислительной среды, в которой может быть реализовано настоящее изобретение. Однако следует иметь в виду, что портативные, переносные и другие вычислительные устройства любого рода пригодны для использования в связи с настоящим изобретением. Хотя ниже описан универсальный компьютер, это описание представляет собой лишь один возможный пример, и настоящее изобретение требует применения только «тонкого клиента», обладающего способностью сетевого взаимодействия и взаимосвязи с сервером. Таким образом, настоящее изобретение может быть реализовано в объединенных в сеть ведущих сервисах, включающих в себя очень незначительное или минимальное использование клиентских ресурсов, например, в сетевой среде, в которой клиентские устройства служат просто как браузер или интерфейс к World Wide Web.

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

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

На фиг.1 представлена приведенная для примера система для реализации изобретения, включающая в себя универсальное вычислительное устройство в форме компьютера 110. Компоненты компьютера 110 могут включать в себя, не ограничиваясь указанным, блок 120 обработки, системную память 130 и системную шину 121, которая связывает различные системные компоненты, включая системную память, с блоком 120 обработки. Системная шина 121 может быть любой из различных типов шинных структур, включая шину памяти или контроллер памяти, шину периферийных устройств, локальную шину, использующую любую из разнообразных шинных архитектур. В качестве примера, но не ограничения, такие архитектуры включают в себя шину ISA (Архитектура, соответствующая промышленному стандарту), шину MCA (Микроканальная архитектура), усовершенствованную шину ISA (EISA), локальную шину VESA (Ассоциации по стандартам в области видеоэлектроники), шину соединения периферийных компонентов (PCI), также известную как шина Mezzanine.

Компьютер 110 в типовом случае включает в себя множество считываемых компьютером сред (носителей). Считываемые компьютером носители могут представлять собой любые известные носители, к которым компьютер 110 может осуществлять доступ, и включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители. К примеру, но не в качестве ограничения, считываемые компьютером носители могут содержать компьютерные носители записи и коммуникационную среду. Компьютерные носители записи включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители, реализованные любым методом или по любой технологии для хранения информации такой, как считываемые компьютером команды, структуры данных, программные модули или иные данные. Компьютерные носители записи содержат, не ограничиваясь указанным, оперативную память (RAM, ОЗУ), постоянную память (ROM, ПЗУ), электронно-стираемую программируемую постоянную память (EEPROM, ЭСППЗУ), память с групповой перезаписью (флэш-память) или другие технологии памяти, CD-ROM, универсальные цифровые диски (DVD) или иные устройства памяти на оптических дисках, магнитных кассетах, магнитных лентах, устройства памяти на магнитных дисках или иные магнитные устройства памяти, или любые иные носители, которые могут быть использованы для хранения требуемой информации и к которым может быть обеспечен доступ компьютера 110. Коммуникационная среда (среда передачи) в типовом случае воплощает считываемые компьютером команды, структуры данных, программные модули или иные данные в модулированном сигнале данных, таком как несущее колебание или иной транспортный механизм, и включает в себя любую среду доставки информации. Термин «модулированный сигнал данных» означает сигнал, у которого одна или более характеристик установлены или изменяются таким образом, чтобы кодировать информацию в сигнале. В качестве примера, но не ограничения, коммуникационная среда включает в себя проводные среды, такие как проводная сеть или прямое проводное соединение, и беспроводные среды передачи, такие как акустическая, радиочастотная, инфракрасная и другие беспроводные среды передачи. Комбинации любых вышеуказанных сред также должны быть включены в объем носителей (сред), считываемых компьютером.

Системная память 130 включает в себя компьютерный носитель записи в форме энергозависимой и/или энергонезависимой памяти, такой как постоянная память (ПЗУ, ROM) 131 и оперативная память (ОЗУ, RAM) 132. Базовая система ввода/вывода (BIOS) 133, содержащая базовые подпрограммы, которые способствуют переносу информации между элементами в компьютере 110, например, при запуске, в типовом случае сохранена в ПЗУ 131. ОЗУ 132 в типовом случае содержит данные и/или программные модули, которые непосредственно доступны и/или обрабатываются блоком 120 обработки. В качестве примера, но не ограничения, на фиг.1 показаны операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 110 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители записи. Например, на фиг.1 показан дисковод 141 жестких дисков для считывания с несъемного, энергонезависимого магнитного носителя и записи на него, дисковод 151 магнитных дисков для считывания со съемного энергонезависимого магнитного диска 152 и записи на него и дисковод 155 оптических дисков для считывания со съемного энергонезависимого оптического диска 156 или записи на оптический диск, такой как, например, ПЗУ на компакт-диске (CD-ROM) или иные оптические носители записи. Другие съемные и несъемные, энергозависимые и энергонезависимые компьютерные носители записи, которые могут быть использованы в приведенной для примера операционной среде, включают в себя, не ограничиваясь указанным, кассеты на магнитных лентах, карты флэш-памяти, DVD, цифровые видеомагнитные ленты, твердотельные ОЗУ, твердотельные ПЗУ и т.п. Дисковод 141 жестких дисков в типовом случае соединен с системной шиной 121 посредством интерфейса несъемной памяти, такого как интерфейс 140, и дисковод 151 магнитных дисков и дисковод 155 оптических дисков соединены с системной шиной 121 в типовом случае посредством интерфейса съемной памяти, такого как интерфейс 150.

Дисководы и связанные с ними считываемые компьютером носители, описанные выше и показанные на фиг.1, обеспечивают хранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 110. На фиг.1, например, показано, что дисковод 141 жесткого диска хранит операционную систему 144, прикладные программы (приложения) 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут быть теми же самыми или отличающимися от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 обозначены отличающимися ссылочными позициями для иллюстрации того, что они, как минимум, являются другими копиями. Пользователь может вводить команды и информацию в компьютер 110 посредством устройств ввода, например клавиатуры 162, и координатно-указательного устройства 161, такого как мышь, трекбол или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя джойстик, игровую панель, спутниковую параболическую антенну, сканер и т.п. Эти и другие устройства ввода часто соединяются с блоком 120 обработки через интерфейс 160 пользовательского ввода, связанный с системной шиной, но могут быть соединены и посредством других интерфейсов и структур шин, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB) и т.д.

Монитор 191 или иное устройство отображения также соединено с системной шиной 121 через интерфейс, например, такой как видеоинтерфейс 190. Графический интерфейс 182, такой как Northbridge, может быть соединен с системной шиной 121. Northbridge является набором микросхем, который осуществляет информационный обмен с центральным процессорным блоком (CPU) или с главным блоком обработки 120 и отвечает за коммуникации с ускоренным графическим портом (AGP). Один или более блоков обработки графики (GPU) 184 могут осуществлять информационный обмен с графическим интерфейсом 182. В этом смысле блоки GPU 184 обычно включают в себя встроенную в кристалл память, такую как регистр памяти, и блоки GPU 184 осуществляют информационный обмен с видеопамятью 186. Однако блоки GPU 184 приведены только в качестве возможного примера сопроцессора, и, следовательно, различные сопроцессорные устройства могут быть включены в состав компьютера 110. Монитор 191 или иное устройство отображения также соединено с системной шиной 121 через интерфейс, например, такой как видеоинтерфейс 190, который, в свою очередь, может осуществлять связь с видеопамятью 186. Помимо монитора 191 компьютеры также могут включать в себя другие периферийные устройства вывода, например громкоговорители 197 и принтер 196, которые могут быть соединены через интерфейс 195 устройств вывода.

Компьютер 110 может работать в сетевой среде с использованием логических соединений с одним или более удаленными компьютерами, такими как удаленный компьютер 180. Удаленный компьютер 180 может представлять собой персональный компьютер (ПК), портативное устройство, сервер, маршрутизатор, сетевой ПК, одноранговое устройство или другой обычный сетевой узел и в типовом случае включает в себя многие или все из элементов, описанных выше применительно к компьютеру 110, хотя на фиг.1 показано только устройство 181 памяти. Логические соединения, показанные на фиг.1, включают в себя локальную сеть (LAN) 171 и глобальную сеть (сеть широкого охвата - WAN) 173, но могут включать в себя и другие сети. Такие сетевые среды являются общеизвестными в офисах, компьютерных сетях предприятий, интранетах и в Интернет.

При использовании в сетевой среде локальной сети (LAN) компьютер 110 соединяется с локальной сетью 171 через сетевой интерфейс или адаптер 170. При использовании в сетевой среде глобальной сети (WAN) компьютер 110 в типовом случае включает в себя модем 172 или иное средство для установления связи в глобальной сети 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, соединен с системной шиной 121 через интерфейс 160 пользовательского ввода или иной подходящий механизм. В сетевой среде программные модули, изображенные по отношению к компьютеру 110, или их части могут быть сохранены в удаленном устройстве памяти. В качестве примера, но не ограничения, фиг.1 иллюстрирует удаленные прикладные программы 185 как хранящиеся в устройстве 181 памяти. Следует иметь в виду, что показанные сетевые соединения приведены для примера и что могут быть использованы и другие средства установления канала связи между компьютерами.

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

Система и способ для использования механизма связывания данных для связывания команд

Фиг.2 иллюстрирует пример системы для использования механизма связывания данных для выполнения связывания команд в соответствии с некоторыми вариантами осуществления изобретения. Такая система может располагаться полностью или частично на одном или более компьютеров, таких как приведенный для примера компьютер 202 на фиг.2. Компьютер 202 может представлять собой такой компьютер, как компьютер 110, описанный в связи с фиг.1. Система для использования механизма связывания данных для маршрутизации команд может содержать один или более из следующих элементов: компонент 208 связывания данных, источник 206 и целевой объект 203.

В некоторых вариантах осуществления изобретения компонент 208 связывания данных является механизмом 208 связывания данных, который обеспечивает динамическое связывание объекта 212а команды объекта источника (например, объектов 210а, 210b, и т.д. источника) с целевым объектом (например, целевыми объектами 204а, 204b и т.д.). Механизм связывания данных может воспринимать уведомления об изменениях свойств на объектах, так чтобы изменение в командном свойстве объекта источника автоматически отражалось на ассоциированном свойстве целевого объекта. Механизм связывания данных может воспринимать уведомления об изменениях свойств на объектах, так чтобы изменение в некомандном свойстве объекта источника автоматически отражалось на ассоциированном свойстве целевого объекта и наоборот. Целевой объект может быть ассоциирован с источником данных, который идентифицирует источник, с которым связан целевой объект. Механизм связывания данных может поддерживать оценку путей свойства, чтобы обеспечивать связывание конкретных частей целевого объекта с конкретными частями источника. В некоторых вариантах осуществления изобретения связывание свойств целевого объекта источника со свойствами команд объекта источника может осуществляться декларативно на языке разметки, таком как HTML (язык разметки гипертекста), XML (расширяемый язык разметки), XAML (расширяемый язык разметки приложений) или на другом подходящем языке разметки. Механизм связывания данных может осуществлять поиск свойства команды объекта источника в источнике данных целевого объекта и выполнять соответствующее обновление данных.

В некоторых вариантах осуществления изобретения генерируется граф объектно-ориентированных объектов, где один, некоторые или все объекты указывают на другие объекты, формирующие граф, где каждая стрелка, указывающая в графе от одного объекта на другой, представляет свойство. Пример графа объектно-ориентированных объектов показан на фиг.6. На фиг.6 объект 602 представляет объект администратора документа, объекты 604 и 606 представляют объекты документа, и объект 608 представляет команду «вырезать». На фиг.6 активным документом является объект 606 документа (обозначенный сплошной линией 603, представляющей свойство «активный документ»). Понятно, что изобретение не ограничено такими объектами и командами. Может оказываться действие на любые подходящие объекты и команды. На самом деле, изобретение не ограничено объектами в среде языка объектно-ориентированного программирования, но равным образом применимо к любому источнику данных и иерархии свойств. В некоторых вариантах осуществления изобретения механизм 208 связывания данных обеспечивает возможность определения источника данных (объект 602) и пути свойства, такого как «Активный документ. Команда «вырезать», представляющего путь от объекта 602 к объекту 606 и к объекту 608. Механизм 208 связывания данных может направить запрос в граф объектов, представляющий «активные» объекты в исполняющейся программе, чтобы динамически определить, какой объект представлен путем «Активный документ. Команда «вырезать» (в данном случае объект 608).

Согласно фиг.2 источник 206 может включать в себя один или более объектов источника, как представлено объектами 210а, 210b и т.д. источника. Объекты 210а, 210b и т.д. источника могут быть ассоциированы с одним или более объектами команды источника, представленными на фиг. 2 объектом 212а команды источника и т.д. В некоторых вариантах осуществления изобретения источник 206 может представлять модель. Модель в некоторых вариантах осуществления изобретения является базовой логикой приложения, представляющей совокупность базового состояния. Например, рассмотрим приложение, которое позволяет пользователю исследовать файловую систему. Модель для приложения в этом случае может представлять собой файловую систему: набор папок и файлов в папках выбранной директории. Ряд представлений (для просмотра) может быть связан с одной моделью. Представления, связанные с моделью, могут зависеть от модели. Однако в некоторых вариантах осуществления изобретения модель не зависит от представления или представлений. Модель может послать уведомление об изменении, если свойство одного из ее объектов изменяется или если происходит изменение в состоянии. Например, если новый файл добавляется к папке, то может быть послано уведомление об изменении.

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

Целевой объект 203 может включать в себя один или более целевых объектов, как представлено на фиг.2 целевыми объектами 204а, 204b и т.д. В некоторых вариантах осуществления изобретения целевой объект может являться представлением или пользовательским интерфейсом. Одно или более представлений могут быть связаны с моделью и отображать состояние базовой модели. В некоторых вариантах осуществления изобретения представление или пользовательский интерфейс определены на языке разметки, таком как HTML (язык разметки гипертекста), XML (расширяемый язык разметки), XAML (расширяемый язык разметки приложений) или на другом подходящем языке разметки, на котором определен вид пользовательского интерфейса и определены элементы или компоненты пользовательского интерфейса. Целевой объект может быть элементом или средством управления пользовательского интерфейса, такими как опция меню, кнопка или окно списка, без ограничений указанным. В описанном выше примере файловой системы пользовательский интерфейс может отображать список текущих файлов в папках выбранной директории.

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

На фиг.3 представлена более детальная блок-схема системы, показанной на фиг.2. Согласно фиг.3 механизм 320 связывания данных может связывать свойство 322 команды в объекте источника (часть модели 324) со свойством на целевом объекте (например, компоненте 330 ПИ). Механизм 320 связывания данных может воспринимать уведомления об изменении свойств (уведомление 326 для свойства 322 модели, уведомление 328 для свойства ПИ) и автоматически синхронизировать источник 324 и целевой объект 330. Целевой объект (например, компонент ПИ) может быть ассоциирован с источником 332 данных, который действует как источник, с которым связан целевой объект).

В некоторых вариантах осуществления изобретения свойство ПИ для связывания (334) представляет собой ввод (прием) или свойство целевого объекта для объекта команды, а свойство модели для связывания (332) представляет собой свойство команды на модели. Неограничительным примером свойства целевого объекта может быть, например, «команда указания («щелчка»)». В некоторых вариантах осуществления изобретения связывание команд реализуется путем назначения модели в качестве источника данных и связывания данных для свойства в компоненте 334 ПИ со свойством команды в модели 332. В некоторых вариантах осуществления связывание может быть реализовано декларативно, не требуя никакого программного кода. Примером декларативного оператора может быть следующий:

<MenuItemClickCommand=”*Bind(DataSource=model,

Path=DocumentManager.ActiveDocument.CutCommand)”/>

Этот оператор означает, что источник данных, ассоциированный с опцией меню «команда указания», является объектом «модель», а объектом, ассоциируемым с «командой указания», является свойство «команда «вырезать» в активном документе. ПИ может быть создан в рамках инструментальных средств разработчика компьютерной графики в разметке, без написания кода, или вне рамок инструментальных средств разработчика компьютерной графики в разметке. Альтернативно тот же самый результат может быть достигнут путем написания программного кода.

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

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

<MenuItem

Text=”*Bind(Path=DocumentManager.ActiveDocument.CutCommand.

Text”/>

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

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

<MenuItemClick=”*Bind(Path=ActiveDocument.Copy)”

Enabled=”*Bind(Path=ActiveDocument.CanCopy)”/>

В этом случае не требуется объекта команды. Состояние CanCopy («может копировать») обеспечивается моделью, и метод Copy() («копировать») связывается с использованием связывания данных.

Фиг.4 иллюстрирует типовой сценарий, в котором может использоваться система для связывания команд согласно некоторым вариантам осуществления изобретения. Рассмотрим приложение, которое манипулирует множеством документов 408, 410 и т.д., один из которых является активным (например, документ 410). Администратор 404 документов (часть модели) может показать свойство для активного документа. Объекты документов 408, 410 и т.д. (часть модели) могут показать команды редактирования в качестве свойств (например, объект 412 команды), которые могут быть выбраны. Декларативное связывание может быть реализовано в некоторых вариантах осуществления изобретения с использованием пути свойства, сначала адресуя активный документ 410 и затем выбирая команду редактирования для активного документа посредством кнопки на пользовательском интерфейсе 402. Пример декларативных операторов связывания может иметь вид:

<MenuItemClickCommand=

”*Bind(Path=DocumentManager.ActiveDocument.CutCommand)”/>

или:

<MenuItemClickCommand=

”*Bind(Path=DocumentManager.ActiveDocument.CopyCommand)”/>

или:

<MenuItemClickCommand=

”*Bind(Path=DocumentManager.ActiveDocument.PasteCommand)”/>

В некоторых вариантах осуществления администратор 404 документов может обеспечивать уведомление об изменениях для любого изменения в свойстве 410 активного документа (например, пользователь изменяет активный документ). Уведомление об изменении обнаруживается механизмом 406 связывания данных, и команда повторно связывается с активным документом. Следует отметить, что в некоторых вариантах осуществления изобретения вышеуказанный результат выполнялся декларативно, без создания программного кода. Для администрирования команд не требуется никакого сервиса.

В некоторых вариантах осуществления изобретения произвольные свойства, которые не являются свойствами команд, могут быть связаны с опциями меню. Например, булево свойство в модели может быть связано опцией меню кнопки-флажка. В некоторых вариантах осуществления изобретения компонент ПИ кнопки-флажка может показывать свойство, например «выбрано», которое может использоваться в качестве свойства целевого объекта. Аналогичным образом, список объекта может быть связан с опцией меню специального окна списка для обращения к сценарию, такому как список «самых последних использованных» файлов, без ограничения указанным.

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

На этапе 508 может генерироваться и/или реализовываться приложение, содержащее модель, и пользовательский интерфейс. Механизм связывания может контролировать пути модели и оценивать оператор связывания команд. Если оператор связывания команд оценивается успешно, то целевой объект и модель могут быть синхронизированы, как описано выше. В некоторых вариантах осуществления изобретения могут быть обеспечены один или более операторов связывания команд. Связывание команд может выполняться путем декларативного назначения одного или нескольких путей команд связывания данных и источников данных источнику, как описано выше. В некоторых вариантах осуществления изобретения путь команды источник данных декларативно определяются на языке разметки, таком как HTML, XML, XAML, или на другом подходящем языке разметки. Пути модели могут непрерывно контролироваться для обнаружения уведомлений об изменениях. Уведомление об изменении может приниматься от объекта команды, указывающего, что свойство команды изменилось. В некоторых вариантах осуществления изобретения уведомление об изменении посылается объектом команды и обнаруживается механизмом привязки данных. Если уведомление об изменении принято, оператор связывания команды может быть повторно оценен и источник и целевой объект синхронизированы, как описано выше. В некоторых вариантах осуществления изобретения механизм связывания данных запрашивает граф объектов для отыскания объекта, указываемого источником данных и путем данных, и механизм связывания данных обновляет автоматически целевой объект посредством характерной процедуры связывания объектов.

Различные методы, описанные выше, могут быть реализованы в связи с аппаратными средствами или программным обеспечением, или, если необходимо, посредством комбинации того и другого. Таким образом, способы и устройства, соответствующие настоящему изобретению, или определенным его аспектам или частям, могут принимать форму программного кода (т.е. команд), воплощенных в физической среде, такой как дискета, ПЗУ на компакт-диске, накопитель на жестких дисках или любой другой машиночитаемый носитель для хранения информации, при этом, когда программный код загружается и исполняется в машине, такой как компьютер, машина становится устройством для реализации изобретения. В случае исполнения программного кода на программируемых компьютерах вычислительное устройство в общем случае включает процессор, носитель для хранения данных, считываемый процессором (включая энергозависимую и энергонезависимую память и/или элементы хранения информации), по меньшей мере, одно устройство ввода и, по меньшей мере, одно устройство вывода. Одна или более программ, которые могут использовать создание и/или реализацию специфических для областей аспектов моделей программирования согласно настоящему изобретению, например, за счет использования API обработки данных и тому подобное, предпочтительно реализуются на процедурном языке высокого уровня или на языке объектно-ориентированного программирования, чтобы осуществлять информационный обмен с компьютерной системой. Однако программы, при необходимости, могут быть реализованы на языке ассемблера или машинном языке. В любом случае язык может быть языком компиляции или интерпретации и может объединяться с реализациями на аппаратных средствах.

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

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

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

2. Система по п.1, в которой команда представляет собой объект команды.

3. Система по п.1, в которой команда ассоциирована с состоянием.

4. Система по п.3, в которой состояние команды выводится из источника.

5. Система по п.3, в которой состояние команды ассоциировано с возможностью ее исполнения.

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

7. Система по п.1, в которой команда представляет метод.

8. Система по п.1, в которой, по меньшей мере, один оператор связывания содержит оператор на декларативном языке разметки.

9. Система по п.8, в которой декларативный язык разметки содержит HTML, XML или XAML.

10. Система по п.1, в которой, по меньшей мере, один оператор связывания содержит указание источника данных.

11. Система по п.1, в которой, по меньшей мере, один оператор связывания содержит путь связывания.

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

13. Система по п.12, в которой второй объект является объектом команды.

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

15. Система по п.1, в которой целевой объект является пользовательским интерфейсом.

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

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

18. Способ по п.17, в котором в ответ на определение, что, по меньшей мере, один оператор связывания оценен безуспешно, значение команды устанавливается на нуль.

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

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

21. Способ по п.17, в котором команда представляет собой объект, ассоциированный с состоянием.

22. Способ по п.21, в котором состояние команды выводится из источника данных.

23. Способ по п.21, в котором состояние команды ассоциировано с возможностью ее исполнения.

24. Способ по п.17, в котором команда является методом.

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

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

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

28. Способ по п.17, в котором, по меньшей мере, один оператор связывания содержит декларативный оператор на языке разметки.

29. Способ по п.28, в котором язык разметки представляет собой HTML.

30. Способ по п.28, в котором язык разметки представляет собой XML.

31. Способ по п.28, в котором язык разметки представляет собой XAML.

32. Способ по п.17, в котором целевой объект является элементом пользовательского интерфейса.

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

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