Система и способ управления свойствами пользовательского интерфейса с помощью данных

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

 

Данная заявка показана как заявка РСТ, поданная 17 мая 2003 г. корпорацией Майкрософт, созданной и находящейся США, с указанием всех стран, кроме США.

Предпосылки изобретения

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

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

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

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

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

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

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

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

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

Подробное описание предпочтительного варианта осуществления

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

Иллюстративная вычислительная среда

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

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

Вычислительное устройство 100 также может содержать средства связи 116, позволяющие устройству 100 осуществлять связь с другими вычислительными устройствами 118, например, по сети. Средства связи 116 являются примером сред связи. Среды связи обычно реализуют считываемые компьютером команды, структуры данных, программные модули или другие данные в модулированном сигнале данных, например, сигнале несущей или ином транспортном механизме и включают в себя любые среды доставки данных. Термин «модулированный сигнал данных» означает сигнал, одна или несколько характеристик которого изменяется определенным образом, что позволяет кодировать информацию в сигнале. В порядке примера, но не ограничения, среды связи включают в себя проводные среды, например, проводную сеть или прямое проводное соединение, беспроводные среды, например, акустические, ВЧ, инфракрасные и другие беспроводные среды. Используемый здесь термин «считываемые компьютером среды» подразумевает как среды хранения данных, так и среды передачи данных.

Иллюстративная реализация

На фиг. 2 показана функциональная блок-схема варианта осуществления системы 200 управления свойствами пользовательского интерфейса с помощью данных согласно настоящему изобретению. Система 200 содержит приложение 202, платформу 220 и источник 230 данных. Приложение 202 может представлять собой одно из приложений 106 на вычислительном устройстве 100, показанном на фиг. 1. Приложение 202 включает в себя код (ниже именуемый логикой 204) для манипулирования значением данных (например, значением 238 данных источника). В общем случае, логика 204 осуществляет проверку правильности значений данных и обновляет значения данных. Значение данных (например, значение 238 данных) представляет содержимое свойства (т.е. свойства источника данных) элемента данных (например, элемента 232 данных). Элемент 232 данных размещен в источнике данных (например, источнике 230 данных). Каждый источник 230 данных может содержать несколько элементов данных, каждый из которых имеет одно или несколько свойств, в которых хранится значение данных источника. Логика 203 может манипулировать значениями данных из множественных источников данных. Источники данных могут включать в себя документ XML, объект, набор данных и т.п. Согласно нижеприведенному подробному описанию, каждое свойство элемента данных можно использовать для управления пользовательским интерфейсом (ПИ).

Приложение 202 также включает в себя код (ниже именуемый пользовательским интерфейсом 206) для представления информации. Пользовательский интерфейс 206 включает в себя несколько элементов пользовательского интерфейса (например, элемент 208 ПИ). Каждый элемент 208 пользовательского интерфейса включает в себя одно или несколько свойств (например, свойства 210 и 212 ПИ), как то: отображаемый текст, цвет, шрифт, положение, размер и т.д. Затем, согласно нижеследующему подробному описанию, эти свойства 210 и 212 ПИ связывают с одним или несколькими значениями 238 и 242 данных, согласно настоящему изобретению. В общем случае, связывание осуществляется машиной («механизмом») 224 привязок, входящей в состав платформы 220. Платформа 220 представляет системный уровень служб, например операционную систему, виртуальную машину и т.п. Платформа 220 также содержит машину 222 свойств, которая отвечает за поддержание иерархической информации, относящейся к значениям 234 и 242 данных, и за обновление соответствующих свойств значениями данных. Хотя машина 224 привязок и машина 222 свойств показаны как раздельные компоненты, специалистам в данной области очевидно, что функции каждой из них, можно объединить в одном компоненте, не выходя за рамки настоящего изобретения.

Связывание (т.е. привязки) значений 238 и 242 данных с их свойствами 210 и 212 ПИ представлено на фиг. 2 пунктирными линиями от значения данных к свойству ПИ (ниже именуемыми привязками 226 и 228). В нижеследующем описании термин «значение данных» может использоваться наравне с термином «значение данных источника». Аналогично, термин «свойство ПИ» может использоваться наравне с термином «целевое свойство». Эти привязки 226 и 228 позволяют автоматически задавать динамические свойства (т.е. целевые свойства) на основании значений данных (т.е. значений данных источника), например, на основании свойств произвольных объектов. Эти привязки могут быть динамическими, что позволяет соответствующему целевому свойству автоматически обновляться, чтобы отражать изменения значения данных источника.

Для обеспечения этой возможности автоматического обновления, настоящее изобретение дополнительно предусматривает механизм извещения (например, представленный на фиг. 2 блоками 236 и 240 извещения и стрелками от блоков извещения к платформе 220). Каждый элемент 232 и 234 данных имеет соответствующий этап 236 и 240 извещения соответственно. Механизм извещения отвечает за информирование системы об изменении значения данных источника и о возможности передачи значения данных на целевое свойство (например, свойство ПИ).

При создании привязок 226 и 228, например, посредством разметки, кода и т.п. машина 234 привязок создает объект привязки (например, объекты 250 и 252 привязки), связанные с привязкой. Например, объект 252 привязки может представлять привязку 228 в машине 224 привязок. Каждый объект привязки включает в себя несколько свойств (например, свойства 260-272 привязки). Каждое из этих свойств 260-272 привязки можно задавать программно. Ниже рассмотрено каждое из этих свойств, и на фиг. 4 показан иллюстративный код для активации привязки, задающий некоторые из этих свойств.

Одно из свойств привязки (ниже именуемое «путь» 260) идентифицирует способ, как найти значение данных источника (через объект источника). Путь 260 может ссылаться на свойство, подсвойство или индексатор на объекте источника, столбец в ADO (ActiveX Data Objects), XPath на XML, и т.п. Альтернативно, путь может ссылаться на отражение или путь ADO.

Другое свойство привязки (ниже именуемое «тип привязки» 264) задает тип для привязок 226 и 228. В одном варианте осуществления, «тип привязки» может принимать значения «односторонняя», «двусторонняя» и «одноразовая». В порядке иллюстрации, привязка 226 представляет собой «двустороннюю» привязку, а привязка 228 представляет собой «одностороннюю» привязку. Один из этих типов привязки является заданным по умолчанию. В одном варианте осуществления типом привязки, принятым по умолчанию, является «двусторонняя» привязка.

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

Когда «тип привязки» 262 имеет значение «двусторонняя», машина 224 привязок должна обновлять целевое свойство при каждом изменении значения данных источника, и наоборот. «Двусторонняя» привязка особенно полезна при привязке данных к окну редактирования, когда любые изменения, внесенные пользователем в окне редактирования, нужно распространить на значение данных источника. Другой сценарий для двусторонней привязки состоит в том, что за поле данных источника отвечает другое приложение, и эти изменения отражаются в окне редактирования.

Когда «тип привязки» 262 имеет значение «одноразовая», машина 224 привязок должна инициализировать целевое свойство один раз и затем оставлять его без изменений даже при изменении соответствующего значения данных источника. Одноразовый тип привязки полезен, когда какое-либо целевое свойство необходимо инициализировать неким значением из поля источника и контекст данных заранее неизвестен. Кроме того, одноразовый тип привязки полезен для использования значений данных источника в режиме «только чтение», если они не подлежат изменению. Если источник данных не поддерживает механизм извещения свойств, отвечающий настоящему изобретению (например, интерфейс IPropertyChange), то целевое свойство, заданное как «одностороннее», будет обновляться аналогично привязке, «тип привязки» которой задан как «одноразовая».

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

Binding.GetBinding(myElement, myProperty).Update();.

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

Еще одно свойство привязки (ниже именуемое «преобразователь» 268) принимает ссылку на класс. Ссылку на класс можно задавать, используя <Namespace>, <Class>, <Assembly>. Машина 224 привязок вызывает заданную ссылку на класс, чтобы преобразовать значение данных источника в формат, принимаемый целевым свойством. Метод в ссылке на класс вызывает это преобразование, представленное на фиг. 2 как преобразователь 244. Ссылка на класс может также задавать обратное преобразование (не показано) для преобразования целевого свойства в формат, принимаемый значением данных источника. Преобразование 244 может обеспечивать семантику ПИ или быть преобразователем заказного типа.

Еще одно свойство привязки (ниже именуемое «культура» 270) указывает, как следует обрабатывать значение данных источника до/после преобразования значения данных источника. «Культура» 270 действует совместно с преобразователем 268, позволяя разработчикам устанавливать правила преобразования значений данных источника. Например, «культура» может задавать конкретный формат чисел, дат и т.д. В одном варианте осуществления, культура 270 принимает значение типа CultureInfo. Разработчик имеет возможность использовать правила, заданные «культурой» 270 при реализации преобразования.

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

Public static void main()

{

//Добавить обработчик

elem.AddAttachedHandler(Binding.DataTranferEvent,

newDataTranferEventHandler(OnDataTransfer),

RoutedEventArgs.EventStage.Direct);

//Обработчик событий

private static void OnDataTransfer(Element e,

DataTransferEventArgs args)

{

DynamicProperty DP=args.DP;

v=e.GetValue(DP);

DoSomething(v);

}

source.field="new value";

}.

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

На фиг. 3 показана логическая последовательность операций механизма привязки согласно одному варианту осуществления настоящего изобретения. В целом, механизм привязки осуществляет действия по установлению привязки (этапы 302-306), а затем осуществляет действия (этапы 310-338), относящиеся к изменениям целевого свойства или значения данных источника, указанным в привязке. Обработка продолжается на этапе 302.

Этап 302 обозначает создание объекта привязки на основании аргументов, заданных при создании. В целом, в качестве аргумента при создании можно задавать каждое свойство (т.е. свойства 260-272, показанные на фиг. 2) для объекта 252 привязки. Привязку можно создавать посредством разметки, программно и т.п. На фиг. 4 показаны иллюстративные синтаксисы для создания привязки и задания свойств 260-272. Каждый способ создания предусматривает задание элемента данных источника, пути к значению данных в элементе данных источника, целевого элемента ПИ и целевого динамического свойства на элементе ПИ. Хотя это и не показано в данной последовательности операций, свойства объекта привязки можно динамически изменять в ходе работы, например, с использованием программных интерфейсов приложения (API). Затем обработка переходит к этапу 304.

Этап 304 обозначает активацию привязки. В одном варианте осуществления, привязка может активироваться автоматически после того, как машина привязок извещает о наличии достаточного контекста для привязки, например, о наличии объекта источника, готовности целевого элемента к отображению (на экране) и т.д. Машина привязок отвечает за распознавание активации привязки. Затем обработка переходит к этапу 306.

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

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

Поэтому, после этапа 308 обработка идет двумя асинхронными путями. Первый путь (этапы 310-318) связан с обновлением целевого свойства, а второй путь (этапы 330-338) связан с обновлением значения данных источника. Ниже описан каждый из этих путей. Сначала опишем путь, отвечающий за обновление целевого свойства.

На этапе 310 принятия решения машина привязок определяет, имеет ли привязка, связанная со значением данных источника и целевым свойством, одноразовый тип привязки. Если «тип привязки» имеет значение «одноразовая», то обработка этой привязки завершается и процесс заканчивается. Специалисту в данной области очевидно, что, если «тип привязки» имеет значение «одноразовая», то машина привязок не отслеживает события изменения свойств источника. Таким образом, на практике, логика в машине привязок не обязана выполнять проверку, указанную этапом 310. Кроме того, если элемент данных не реализует IPropertyChange, то обработка завершается. Если же «тип привязки» не имеет значение «одноразовая», то обработка переходит к этапу 312.

На этапе 312 машина привязок отслеживает извещения, связанные с привязками. Поскольку «привязка данных» напрямую не обновляет цель значением данных источника, настоящее изобретение реализует механизм извещения. Механизмы извещения, например извещения об изменении свойств и извещения "CurrentChanged" вида коллекции и т.п., известны в технике и не нуждаются в дальнейшем обсуждении. Извещения обусловлены разными действиями, например, изменением значения данных, навигацией по странице, отключением, изменением нужной записи в коллекции данных и т.п. Поскольку настоящее изобретение предусматривает обновление при изменении нужной записи в коллекции данных, настоящее изобретение обеспечивает удобный механизм дополнительного разъединения пользовательского интерфейса и логики. Например, согласно настоящему изобретению, разработчику нужно только написать код в логике, чтобы указать, как переходить к следующей нужной записи в коллекции данных. Когда происходит изменение, машина привязок, согласно настоящему изобретению, обновляет пользовательский интерфейс в соответствии с уже заданными привязками. Согласно вышеизложенному, это разъединение пользовательского интерфейса и логики обеспечивает более устойчивое и более просто поддерживаемое приложение, чем «переплетенные» пользовательский интерфейс и логика.

Нижеследующий код является одной иллюстративной реализацией механизма извещения. Хотя представленный ниже иллюстративный код написан на C#, специалистам в данной области очевидно, что для реализации механизма извещения можно использовать различные языки и синтаксис. Для любой такой реализации, интерфейс задается для использования каждым элементом данных. Каждый элемент данных наследует этот интерфейс в целях реализации динамического обновления.

public interface IPropertyChange

{

event PropertyChangedEventHandler PropertyChanged;

}

Затем задают обработчик событий и его аргументы.

public delegate void PropertyChangedEventHandler(object sender,

PropertyChangedEventArgs e);

public class PropertyChangedEventArgs: EventArgs

{

public virtual string PropertyName { get;}

}.

Класс PropertyChangedEventArgs содержит одно свойство с возможностью только чтения, названное PropertyName, имеющее тип «строка». Свойство PropertyName содержит имя свойства, которое изменилось. Затем, каждый элемент данных источника реализует этот интерфейс, вызывая делегат PropertyChanged всякий раз при изменении одного из его свойств. Ниже приведен иллюстративный пример реализации объекта источника (например, элемента 232 данных) согласно варианту осуществления механизма извещения.

public class myClass: IPropertyChange

{

private string foo = "Hello World";

public string Foo

{

get { return foo; }

set { if(foo != value)

{

foo = value;

NotifyPropertyChanged("foo");

}

}

public event PropertyChangedEventHandler Property Changed;

private void NotifyPropertyChanged(string propName)

{

PropertyChanged(this, new

PropertyChangedEventArgs(propName));

}

}.

Согласно вышеприведенному иллюстративному коду, метод 'set' для свойства 'foo' определяет, отличается ли новое значение от старого значения. Если значения различаются, вызывается обработчик. Для получения PropertyInfo осуществляется отражение. Согласно дополнительному усовершенствованию, машина привязок может кэшировать тип свойства после того, как оно получено посредством отражения. Таким образом, отражение осуществляется однократно, а не каждый раз при получении извещения для свойства. Согласно другому усовершенствованию, в аргументах можно передавать пустую строку, чтобы сигнализировать, что все привязки к каждому из значений данных элемента данных следует обновить. Это может иметь место, когда объект источника не располагает информацией о том, какие свойства изменились, и поэтому желательно обновить каждую привязку. После того, как машина привязок получает извещение об изменении значения данных источника, обработка переходит к этапу 314 принятия решения.

Этап 314 принятия решения обозначает выяснение, задано ли в привязке, связанной с измененным значением данных источника, преобразование для привязки. Если в привязке не задано преобразование, то обработка переходит к этапу 318. Если же в привязке задано преобразование, то обработка переходит к этапу 316.

Этап 316 обозначает выполнение преобразования, заданного в привязке. В одном варианте осуществления, преобразователь 268 представляет собой описанный ниже объект:

public interface IDataTransformer

{

public object Transform(object o, DynamicProperty dp,

CultureInfo c) {;}

}.

Для вышеописанного интерфейса, «о» обозначает значение источника, «dp» обозначает целевое динамическое свойство, и «с» обозначает культуру для использования в ходе преобразования. Метод Transform() преобразует значение «о» источника в объект, пригодный для присвоения динамическому свойству типа «dp». Метод Transform() вызывается при распространении значения данных от источника привязки на целевое свойство. Если метод Transform() возвращает значение null, то машине привязок предписывается остановить распространение значений.

Преобразователь также можно использовать для управления другими свойствами ПИ, например, шириной, высотой, шрифтом, расположением (x,y) и т.п. на основании соответствующего значения данных источника, заданного в привязке. Преобразователи обеспечивают возможность осуществлять логику в отношении значений данных, чтобы показывать данные несколькими способами. Согласно дополнительному усовершенствованию в ходе преобразования можно применять культуру, согласно указанному в привязке. Затем обработка переходит к этапу 318.

Этап 318 обозначает обновление целевого свойства. В одном варианте осуществления машина свойств присваивает значение целевому свойству. Кроме того, целевое свойство можно пометить как имеющее новое значение. Затем обработка может перейти к этапу 312 для отслеживания следующего извещения об изменении свойства, связанного с привязкой. Когда приложение заканчивает работу, или привязка иным образом завершается, обработка заканчивается.

Согласно отмеченному выше, после этапа 308, обработка может пойти по второму пути. Таким образом, после этапа 308, обработка переходит к этапу 330 принятия решения. Согласно отмеченному выше в отношении этапа 310 принятия решения, логика в машине привязок не всегда осуществляет проверку «типа привязки» на блоке 310 принятия решения, поэтому, если машина привязок не получает предписания отслеживать извещения о создании привязки, процесс не проходит второй путь. Однако для упрощения описания хода процесса, показан этап принятия решения, отражающий «тип привязки». Таким образом, этап 330 принятия решения обозначает выяснение, имеет ли привязка в качестве «типа привязки» значение «двусторонняя». Согласно рассмотренному ранее, двусторонняя привязка позволяет распространять изменения целевого свойства на значение данных источника. Если «тип привязки» для привязки не имеет значение «двусторонняя», то обработка заканчивается. Если же привязка имеет двусторонний тип привязки, то обработка переходит к этапу 332.

На блоке 332 машина привязок выявляет определенные действия, которые запускают обновление значения данных источника. В случае запуска, обработка переходит к этапу 334 принятия решения.

Этап 334 принятия решения обозначает выяснение, задано ли в привязке обратное преобразование для привязки. Если привязка не задает обратное преобразование, то обработка переходит к этапу 338. Если же привязка задает обратное преобразование, то обработка переходит к этапу 336.

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

public interface IDataTransformer

{

public object InverseTransform(object o, PropertyInfo

pinfo.CultureInfo c){;}

}.

Для вышеописанного интерфейса «о» обозначает значение источника, «с» обозначает культуру для использования в ходе преобразования, и «pinfo» обозначает PropertyInfo целевого свойства. Метод InverseTransform() преобразует значение «о» источника в объект, пригодный для присвоения свойству информации типа. Этот метод вызывается при передаче значения от цели привязки на источник. Если метод InverseTransform() возвращает значение null, то машина привязок не передает значение. После выполнения InverseTransform, обработка переходит к этапу 338.

Этап 338 обозначает обновление свойства источника в соответствии с «типом обновления». Согласно описанному выше, «тип обновления» может иметь значения «немедленно», «при потере фокусировки», «явно» и другие. После обновления свойства источника обработка заканчивается.

На фиг. 4 показано несколько иллюстративных средств создания привязки. Средство 400-410 создания создает привязку посредством разметки. Средство 412 создания создает привязку посредством кода. Иллюстративные средства, показанные на фиг. 4, не являются единственно возможными. Можно использовать другие средства (синтаксис), не выходя за рамки объема настоящего изобретения.

Средство 400 создания содержит пару имя/значение DataContext [контекст данных] (ниже именуемую DataContext 422) и пару имя/значение Id [идентификатор] (ниже именуемую Id 420) для элемента 424. Поскольку средство 400 создания также содержит DataContext 422, то Id 420 является необязательной. Id 420 нужна, когда желательно сослаться на явный источник, например, с использованием ElementSource в разметке или IdObjectReg в коде. Оба эти варианта использования описаны ниже. DataContext 422 - это динамическое свойство, заданное (определенное) на элементе (например, элементе 424). Значение, связанное с DataContext 422, представляет элемент данных источника, принятый по умолчанию, и является наследуемым свойством. Машина привязок запрашивает DataContext 422 и использует DataContext 422 при создании элемента 424 и элементов-потомков (например, элемента 426 Button [кнопка]). Машина привязок также отслеживает изменения DataContext 422, что соответственно, запускает обновление. Таким образом, хотя это и не требуется, DataContext 422 обеспечивает удобный механизм установления области действия для всех свойств, связанных с общим элементом данных. Элементы-потомки могут иметь собственные DataContext, которые будут иметь приоритет над DataContext 422 родительского элемента. Привязка может подменять DataContext 422, обеспечивая Source [источник], не равный null, описанный ниже применительно к средству 402 создания.

Элемент 426 Button проиллюстрирован с целевым свойством (например, Button.Text 428). Согласно настоящему изобретению, встретив «Data:Bind», машина привязок распознает, что привязка задана. Последующие пары имя/значение устанавливают свойства 260-272 привязки, указанные на фиг. 2. Специалистам в данной области очевидно, что элемент «Data:Bind» для сигнализации о привязке выбран произвольно, и можно использовать любое количество элементов, не выходя за рамки настоящего изобретения. Средство 400 создания представляет расширенный формат разметки.

Средство 402 создания представляет компактный формат разметки. Свойство ПИ (например, Button Text) представлен в более компактном виде. Опять же, «Data:Bind» используется как сигнал машине привязок о том, что далее следует привязка. Кроме того, пары имя/значение, следующие после Data:Bind, соответствуют нужным свойствам 260-272, описанным выше для объекта 250 привязки на фиг. 2. Например, пара имя/значение ElementSource (ниже именуемая ElementSource 434) соответствует источнику 266.

В языке разметки имеются два метода задания свойства источника: ElementSource и DataSource. Если ни один из них не используется, то источнику присваивается значение null по умолчанию, что предписывает машине привязок после создания получить значение свойства DataContext элемента и использовать это значение в качестве объекта источника.

Когда средство создания (например, средство 402 создания) задает ElementSource, машина привязок находит элемент, чей ИД указан свойством ElementSource. Затем, DataContext этого элемента используется в качестве объекта источника. Для задания источника данных можно использовать относительные имена пути, например, /Parent/Parent и /Previous/Previous. Когда машина привязок встречает /Parent, она ищет элемент, являющийся родителем по отношению к текущему элементу, в рамках иерархии объектов. Например, если элемент является заданием заказчика, то, задав /Parent, можно предписать машине привязок искать элемент, соответствующий заказчику текущего задания. Задавать /Parent полезно в случаях вложенного повторителя, когда желательно использовать значения от внешнего повторителя в пределах внутреннего повторителя. Задание /Previous предписывает машине привязок искать элемент, предшествующий текущему элементу в соответствии с «повторителем». Задавать /Previous полезно, когда желательно обращаться не только к текущему элементу, но и к элементу с номером «текущий-n», например, в реберных графах и т.п. Согласно настоящему изобретению, можно использовать последовательные /Previous и /Parent.

В другом варианте осуществления разметка может задавать DataSource. Когда задан DataSource, машина привязок принимает ИД ресурса для «ресурса». Если «ресурс» обнаруживает свойство данных, то машина привязок задает «источник» привязки к объекту, возвращенному свойством данных ресурса DataSource. В противном случае, машина привязок устанавливает источник привязки на сам объект ресурса.

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

Следующие три средства 404-410 создания обеспечивают иллюстративные примеры, относящиеся к типу элементов, которые позволяют привязывать настоящее изобретение. Средство 404 создания иллюстрирует поддержку привязки к подсвойствам и индексаторам. Средство 404 создания соответствует привязке, написанной на С# как di.a.b[3].c, где di это соответствующий элемент данных. Пока элемент данных, класс, реализующий di.a, класс, реализующий di.a.b, и класс, реализующий di.a.b[3].c, поддерживают механизм извещения, отвечающий настоящему изобретению, (например, IPropertyChange) и извещают об изменении своих свойств, привязка, заданная с использованием средства 404 создания, предписывает машине привязок автоматически обновлять связанное свойство (например, целевое свойство), чтобы отражать изменения значения данных источника.

Средство 406 создания иллюстрирует поддержку привязки к коллекции данных. Машина привязок автоматически использует текущую запись коллекции на каждом уровне (где, a, b и с представляют разные уровни). Например, если di.a имеет тип IDataCollection, то, для выбора свойства «b», привязка использует текущую запись коллекции. Таким образом, всякий раз при изменении текущей записи машина привязок автоматически обновляет значения, связанные с коллекцией данных.

Средство 408 создания иллюстрирует поддержку привязки к узлу XML. Путь 260 к значению обеспечивается с помощью выражения xpath, например, «/Customer/Order[@OrderID=10]/Amount», показанного на фиг. 4. Средство 410 создания иллюстрирует привязку к таблицам данных ADO. Для этой реализации путь 260 к значению обеспечивается как имя поля для конкретной строки, например, «OrderID», показанное на фиг. 4.

Средство 412 создания создает привязки программно. Разработчик обеспечивает объектную ссылку (objectref) на объект, который привязка должна использовать в качестве элемента данных источника. Операторы программы, показанные в средстве 412 создания, создают привязку, которая ведет себя так же, как проиллюстрированная средством 410 создания. Метод SetBinding имеет ряд более тщательно разработанных вариантов, посредством которых программист может задавать любое из рассмотренных выше свойств привязки. В вышеприведенном простом примере в качестве объекта источника используется DataContext кнопки. Нижеследующие операторы программы создают одностороннюю привязку, в которой в качестве источника используется конкретный объект (известный как рабочий цикл):

Object source =... некоторый произвольный объект... ;

Binding. SetBinding(myButton, Element.BackgroundProperty,

"Color", BindType.OneWay, new ExplicitObjectRef(source));

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

<Test TextContent="*Data:Bind(Path=myInteger)"

Foreground="*Data:Bind(Path=MyInteger;

Transformer=MyTransformer)"/>

public class MyTransformer: IDataTransformer

{

public object Transform(object o, DynamicProperty dp,

CultureInfo culture)

{

if((int)o<0) return Red;

else return Black;

}

public object InverseTransform(object o, PropertyInfo

info, CultureInfo culture)

{

return null;

}

}.

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

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

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

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

3. Компьютерная система по п.1, отличающаяся тем, что создание привязки включает в себя задание типа привязки для выполнения привязки.

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

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

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

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

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

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

10. Компьютерная система по п.1, отличающаяся тем, что создание привязки задается с использованием программного кода.

11. Компьютерная система по п.1, отличающаяся тем, что создание привязки задается с использованием языка разметки.

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

13. Считываемая компьютером среда по п.12, отличающаяся тем, что спецификация привязки задается программно.

14. Считываемая компьютером среда по п.12, отличающаяся тем, что спецификация привязки задается с использованием языка разметки.

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

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

17. Считываемая компьютером среда по п.15, отличающаяся тем, что спецификация привязки дополнительно идентифицирует тип привязки.

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

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

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

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

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

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

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

25. Считываемая компьютером среда по п.12, отличающаяся тем, что источник данных задается посредством XPath в XML, либо столбца в объекте данных ActiveX (ADO), либо отражения.