RU2358307C2 - System and method of controlling user interface properties using data - Google Patents

Abstract

FIELD: physics; computer engineering.

SUBSTANCE: present invention relates to systems and methods of controlling properties of a user interface using data. The application is divided into independent parts, a logic part and a user interface part. The logic part manipulates data values in the application. The user interface part is responsible for displaying user interface properties. A binding specification describes the interrelationship between the user interface properties and data value. A system level code uses the binding specification to determine how it informs on data changes and how it orders the user interface part to display changes in the user interface properties. The binding specification identifies the source data element, the path to the data value in the source data element, the user interface target element and the user interface property on the user interface target element. Binding can be done using a code or mark-up language.

EFFECT: separation of user interface and data from application logic due to provision for a mechanism of binding data to the user interface.

25 cl, 4 dwg

Description

This application is shown as the PCT application, filed May 17, 2003 by Microsoft, created and located in the United States, listing all countries except the United States.

BACKGROUND OF THE INVENTION

The user's ability to understand and comprehend information depends on how the information is presented to users. On computer displays, it has become a tradition to highlight individual pieces of information using colors, font styles, etc. This selection method allows users to easily perceive the importance of information. The code that controls the presentation of information (user interface) and the code that runs the application logic on the information are usually closely interconnected. For example, logic assigns user interface properties (e.g. color, font, position, size) directly using data. Thus, when changing the user interface, the logic must also change. For example, in the case of a text box, the user interface code monitors the change in text, and in the case of a change, the user interface code confirms the correctness of the changed text, and then displays the changed text. Such a close relationship between the user interface and logic causes the fragility of the code. Maintaining this short-lived code is very expensive and time consuming.

SUMMARY OF THE INVENTION

The present invention relates to a system and method for controlling a user interface using data. The invention allows to separate the user interface and data from the application logic, by providing a mechanism for binding data to the user interface. The invention allows user interface developers and application authors who write application logic to work independently. Neither the developers nor the authors need to understand each other's codes, and none of them affects the development of the other. This invention also makes it very easy to make changes to the user interface. For example, when new and more attractive user interface platforms appear, or if the user interface developer wants to change the appearance of the application, the developer is not required to make changes to the application logic. In addition, the mechanism for binding data to the user interface is dynamic. This allows you to automatically reflect any data changes in the view. In addition, any user input through the user interface can automatically update data. Due to the fact that the present invention allows to link not only the display aspects of user interface data (e.g., text), but also the visual aspects (e.g., background, font size, etc.), a descriptive, visually enhanced and flexible presentation of the data can be provided. For example, you can display negative numbers in red or indicate the growth of the stock price with the arrow pointing up.

Thus, according to the present invention, the application is divided into independent parts, a logic part and a PI part. Part of the logic manipulates data values in an application. Part of the PI is responsible for reporting data. The binding specification describes the relationship between the PI property and the data value. The binding specification is used by the system level code to determine how it is notified of a change in the data value and how it directs parts of the UI to reflect the change in the UI property. The binding specification identifies the source data element, the path to the data value in the source data, the target PI element, and the PI property on the target PI element. The binding can be specified using a code or markup language.

Brief Description of the Drawings

FIG. 1 is a block diagram of an illustrative computing device that can be used in illustrative implementations of the present invention.

FIG. 2 is a functional block diagram of one embodiment of managing user interface properties using data according to the present invention.

FIG. 3 is a flowchart of a process for associating a user interface with a data value according to one embodiment of the present invention.

FIG. 4 illustrates several illustrative syntaxes for associating user interface properties with data according to the present invention.

Detailed Description of a Preferred Embodiment

The present invention relates to a system and method for controlling a user interface using data. The invention allows to separate the user interface from the application logic, by providing a mechanism for linking data with the user interface. According to the following detailed description, this separation of the user interface and data from the corresponding logic allows different groups of developers to work independently on the user interface and logic, without affecting the development of the code of another group. In addition, according to the following detailed description, the present invention provides a system and mechanism for automatically transmitting values from data sources to a user interface and vice versa. In the following description, the term “data binding” means the process of associating data values with PI properties, transferring and updating data values, etc.

Illustrative Computing Environment

In FIG. 1 shows an illustrative computing device that can be used in illustrative implementations of the present invention. 1, in each basic configuration, computing device 100 typically comprises at least one processor 102 and system memory 104. Depending on the specific configuration and type of computing device 100, system memory 104 may be a volatile memory device (eg, RAM) non-volatile storage device (e.g., ROM, flash memory, etc.) or any combination thereof. System memory 104 typically houses the operating system 105, one or more program modules 106, and optionally program data 107. Examples of program modules 106 may include a browser application, a financial management application, a text editor, etc. This basic configuration is shown in FIG. 1 components surrounded by a dashed line 108.

Computing device 100 may have additional features or functions. For example, computing device 100 may also include additional storage devices with removable and / or stationary media, which can be magnetic disks, optical disks, or tape. Such additional storage devices are shown in FIG. 1 in the form of a storage device 109 with removable media and a storage device 110 with a stationary medium. Computer storage media can include volatile and non-volatile, removable and stationary storage media that implement any method and any technology for storing information, such as computer-readable instructions, data structures, program modules or other data. System memory 104, storage device 109 with removable media and storage device 110 with stationary media are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROMs, digital versatile disks (DVDs) or other optical storage devices, magnetic tapes, magnetic tape, storage devices based on magnetic disks or other magnetic media, or any other medium that can be used to store useful information and which can be accessed by computing device 100. Any such computer storage medium for data may be included in the device 100. The computing device 100 may also contain an input device (a) 112, for example, a keyboard, mouse, pen, voice input device, tactile input device, etc. It may also comprise an output device (a) 114, for example, a display, speakers, printer, etc. These devices are well known in the art and do not need additional description.

Computing device 100 may also include communication means 116, allowing device 100 to communicate with other computing devices 118, for example, over a network. Communications 116 are an example of communications media. Communication media typically implement computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier signal or other transport mechanism, and include any data delivery medium. The term "modulated data signal" means a signal, one or more of whose characteristics changes in a certain way, which allows you to encode information in the signal. By way of example, but not limitation, communication media include wired media, such as a wired network or a direct wired connection, wireless media, such as acoustic, RF, infrared, and other wireless media. As used herein, the term “computer-readable media” refers to both storage media and data transmission media.

Illustrative implementation

In FIG. 2 is a functional block diagram of an embodiment of a system 200 for managing user interface properties using data according to the present invention. System 200 comprises an application 202, a platform 220, and a data source 230. Application 202 may be one of applications 106 on computing device 100 shown in FIG. 1. Application 202 includes code (hereinafter referred to as logic 204) for manipulating a data value (eg, source data value 238). In general, logic 204 verifies the validity of data values and updates data values. A data value (e.g., data value 238) represents the contents of a property (i.e., a property of a data source) of a data item (e.g., data item 232). Data element 232 is located in a data source (e.g., data source 230). Each data source 230 may contain several data elements, each of which has one or more properties in which the value of the source data is stored. Logic 203 may manipulate data values from multiple data sources. Data sources may include an XML document, an object, a data set, and the like. According to the following detailed description, each property of a data item can be used to control a user interface (UI).

Application 202 also includes code (hereinafter referred to as user interface 206) for presenting information. User interface 206 includes several user interface elements (e.g., UI element 208). Each user interface element 208 includes one or more properties (e.g., PI properties 210 and 212), such as: display text, color, font, position, size, etc. Then, according to the following detailed description, these PI properties 210 and 212 are associated with one or more data values 238 and 242 according to the present invention. In general, the binding is done by the machine ("mechanism") 224 bindings, which is part of the platform 220. Platform 220 represents the system level of services, such as the operating system, virtual machine, etc. The platform 220 also includes a property machine 222, which is responsible for maintaining hierarchical information related to data values 234 and 242, and for updating the corresponding properties with data values. Although the binding machine 224 and the property machine 222 are shown as separate components, it will be apparent to those skilled in the art that the functions of each of them can be combined into a single component without departing from the scope of the present invention.

The binding (i.e., binding) of the data values 238 and 242 to their PI properties 210 and 212 is shown in FIG. 2 by dashed lines from the data value to the PI property (hereinafter referred to as bindings 226 and 228). In the following description, the term “data value” may be used along with the term “source data value”. Similarly, the term “PI property” can be used along with the term “target property”. These bindings 226 and 228 allow you to automatically set dynamic properties (i.e., target properties) based on data values (i.e., source data values), for example, based on properties of arbitrary objects. These bindings can be dynamic, which allows the corresponding target property to be automatically updated to reflect changes in the value of the source data.

To provide this automatic update capability, the present invention further provides a notification mechanism (for example, as shown in FIG. 2 by notification units 236 and 240 and arrows from the notification units to platform 220). Each data element 232 and 234 has a corresponding notification step 236 and 240, respectively. The notification mechanism is responsible for informing the system about a change in the value of the source data and about the possibility of transmitting the data value to the target property (for example, the PI property).

When creating bindings 226 and 228, for example, through markup, code, etc. binding machine 234 creates a binding object (e.g., binding objects 250 and 252) associated with the binding. For example, the binding object 252 may represent the binding 228 in the binding machine 224. Each binding object includes several properties (for example, properties 260-272 of the binding). Each of these binding properties 260-272 can be set programmatically. Each of these properties is discussed below, and in FIG. 4 illustrates an example binding activation code defining some of these properties.

One of the binding properties (hereinafter referred to as the "path" 260) identifies a way to find the value of the source data (through the source object). Path 260 may refer to a property, sub-property, or indexer on the source object, a column in ADO (ActiveX Data Objects), XPath in XML, and so on. Alternatively, the path may refer to a reflection or ADO path.

Another binding property (hereinafter referred to as “binding type” 264) sets the type for bindings 226 and 228. In one embodiment, the “binding type” can be one-way, two-way, and one-time. By way of illustration, anchor 226 is a “two-way” anchor, and anchor 228 is a “one-way” anchor. One of these binding types is the default. In one embodiment, the default binding type is two-way binding.

When the “binding type” 262 is set to “one-way,” the binding machine 224 must update the target property (eg, PI property 210) each time the associated value of the source data changes. A one-way type of binding is useful for binding a data value to an uneditable PI property, such as text color, text background, etc. Using a one-way binding type avoids the overhead of a two-way binding type, which is described below. This reduction in overhead costs is most noticeable when tracking changes in the properties of PI related to the content of the placement (on the screen). For these PI properties, the dynamic properties of each descendant of the PI property must be monitored for changes in the PI property. A one-way binding type can also be useful when the PI property is changed only to show another detail of the view.

When the “binding type” 262 is set to “two-way,” the binding machine 224 must update the target property each time the value of the source data changes, and vice versa. Two-way binding is especially useful when binding data to the editing window, when any changes made by the user in the editing window need to be extended to the value of the source data. Another scenario for two-way binding is that another application is responsible for the source data field, and these changes are reflected in the editing window.

When the “binding type” 262 is “one-time”, the binding machine 224 must initialize the target property once and then leave it unchanged even when the corresponding source data value changes. A one-time type of binding is useful when any target property needs to be initialized with a certain value from the source field and the data context is not known in advance. In addition, a one-time type of binding is useful for using source data values in read-only mode if they cannot be changed. If the data source does not support the property notification mechanism of the present invention (for example, the IPropertyChange interface), then the target property specified as “one-way” will be updated in the same way as the binding, the “binding type” of which is specified as “one-time”.

Another binding property (hereinafter referred to as “update type” 264) sets the update type for the case when the “binding type” 262 is set to “two-way”. Typically, two-way bindings track changes to the target property and propagate those changes back to the value of the source data. This process is called updating the source. Typically, an update is desirable for any changes to the target property. However, in some cases, updating after each keystroke leads to the expenditure of quanta of calculations and does not allow the user to correct typos, etc. The “Update Type” 264 allows the user to indicate when to update. In one embodiment, the “update type” 264 may be “immediately”, “when the focus is lost”, and “explicitly”. Updating “immediately” means that the binding machine must update the value of the source data after each change to the target property. The “in case of focus loss” update means that the binding machine should update the value of the source data after the target element has lost “keyboard focus”. Updating “explicitly” means that the binding machine should only update the value of the source data when the application explicitly requests the update. Typically, this explicit request is made through a method. Although this method can be called for any value of the "update type" 264, the method is useful when the "update type" is set to "explicitly". Here is one example method:

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

Another binding property (hereinafter referred to as “source” 266) identifies the source data element for the binding. In general, as shown in FIG. 4 and described in connection with it, the property "source" 266 can be set programmatically or by markup. When programming, the developer provides an object link (objectref) to the object that the binding should use as an element of the source data. In general, as described in detail in connection with FIG. 4, there are various methods for setting a source property through markup.

Another binding property (hereinafter referred to as a “converter” 268) accepts a class reference. The class reference can be set using <Namespace>, <Class>, <Assembly>. The binding machine 224 calls a predetermined class reference to convert the value of the source data to the format accepted by the target property. The method in the class reference invokes this transformation, shown in FIG. 2 as a transformer 244. A class reference can also specify an inverse transform (not shown) to convert the target property into the format accepted by the value of the source data. Transformation 244 may provide the semantics of PI or be a custom type converter.

Another binding property (hereinafter referred to as “culture” 270) indicates how to process the value of the source data before / after converting the value of the source data. Culture 270 acts in conjunction with transducer 268, allowing developers to establish rules for converting source data values. For example, “culture” may specify a specific format for numbers, dates, etc. In one embodiment, culture 270 assumes a value of type CultureInfo. The developer is able to use the rules defined by the "culture" 270 when implementing the transformation.

Another binding property (hereinafter referred to as “binding flags” 272) provides a mechanism for receiving events that signal data transfer. Because the above data binding method is asynchronous, the “binding flags" 272 let the developer know when the target has been updated with the new value. To use this mechanism, “anchor flags” 272 are set to the value “notify upon transfer”. Then, for the event, a handler is registered in any usual way. The following is an example of using this mechanism:

Public static void main ()

{

// Add handler

elem.AddAttachedHandler (Binding.DataTranferEvent,

newDataTranferEventHandler (OnDataTransfer),

RoutedEventArgs.EventStage.Direct);

// event handler

private static void OnDataTransfer (Element e,

DataTransferEventArgs args)

{

DynamicProperty DP = args.DP;

v = e.GetValue (DP);

DoSomething (v);

}

source.field = "new value";

}.

According to the above illustrative code, when an OnDataTransfer event occurs, the developer learns about updating the dynamic property. Thus, the developer can use the target value for further processing.

In FIG. 3 is a flow chart of a binding mechanism according to one embodiment of the present invention. In general, the binding mechanism takes actions to establish the binding (steps 302-306), and then takes actions (steps 310-338) related to changes in the target property or value of the source data specified in the binding. Processing continues at block 302.

Step 302 denotes the creation of the binding object based on the arguments specified at creation. In general, each property (i.e., properties 260-272 shown in Fig. 2) for the binding object 252 can be set as an argument during creation. A binding can be created using markup, software, etc. In FIG. 4 illustrates illustrative syntaxes for creating bindings and setting properties 260-272. Each creation method involves setting the source data element, the path to the data value in the source data element, the target PI element, and the target dynamic property on the PI element. Although not shown in this sequence of operations, the properties of the binding object can be dynamically changed during operation, for example, using application programming interfaces (APIs). Processing then proceeds to step 304.

Step 304 indicates the activation of the binding. In one embodiment, the binding can be activated automatically after the binding machine notifies that there is sufficient context for the binding, for example, the presence of a source object, the readiness of the target element for display (on the screen), etc. The binding machine is responsible for recognizing binding activation. Processing then proceeds to block 306.

Step 306 denotes finding the value of the specified source property. In one embodiment, reflection is used to find the value. “Reflection” is a general mechanism that allows the caller to receive information about the requested object. Information includes supported objects, “public” (open) properties, etc. In another embodiment, when the data element is a collection (set), the binding engine performs a series of heuristics to determine whether to use the current record or the data object (collection) itself. The first heuristic is applied when the binding refers to a property or indexer. In this case, the corresponding property (s) or indexer on the collection object is used, if such property (s) or indexer exists. Alternatively, the current collection record is used as a data item. Other heuristics are applied in the absence of property and indexer. In this case, the collection object is used for the target property as long as the collection object is valid. Otherwise, the current record is used. Before proceeding to step 308, a transformation is applied to the value if the binding defines the transformation (step 307). The application of the transform is described in detail below in connection with block 316. Then, the processing proceeds to step 308.

Step 308 denotes the purpose (assignment) of the found value to the target property. In one embodiment, a property machine responsible for maintaining a hierarchy of properties can assign a value. In another embodiment, the transformation specified when the binding was created can be called to convert the value before assigning the value to the target property. According to a further refinement, a property machine can mark a property as having a new value. After completing steps 302-308, the binding machine is ready to update the target properties and values of the source data as necessary. In general, the binding mechanism is asynchronous.

Therefore, after step 308, processing proceeds in two asynchronous paths. The first path (steps 310-318) is associated with updating the target property, and the second path (steps 330-338) is associated with updating the source data value. Each of these paths is described below. First, we describe the path responsible for updating the target property.

At decision block 310, the binding machine determines whether the binding associated with the source data value and the target property has a one-time binding type. If the "type of binding" has the value "one-time", then the processing of this binding ends and the process ends. It will be apparent to those skilled in the art that if the “binding type” is “one-time”, then the binding machine does not track events that change source properties. Thus, in practice, the logic in the binding machine is not required to perform the verification indicated by step 310. In addition, if the data element does not implement IPropertyChange, then the processing is completed. If the “binding type” does not have a “one-time” value, then processing proceeds to step 312.

At 312, the binding machine monitors the notifications associated with the bindings. Since “data binding” does not directly update the target with the value of the source data, the present invention implements a notification mechanism. Notification mechanisms, for example, notifications of changes in properties and notifications of "CurrentChanged" type of collection, etc., are known in the art and do not need further discussion. Notifications are caused by various actions, for example, changing the data value, navigating the page, turning it off, changing the desired record in the data collection, etc. Since the present invention provides for updating when changing the desired record in the data collection, the present invention provides a convenient mechanism for additional separation of the user interface and logic. For example, according to the present invention, a developer only needs to write code in the logic to indicate how to proceed to the next desired record in the data collection. When a change occurs, the binding machine according to the present invention updates the user interface in accordance with already defined bindings. According to the above, this separation of the user interface and logic provides a more stable and simpler supported application than the "intertwined" user interface and logic.

The following code is one illustrative implementation of the notification mechanism. Although the illustrative code below is written in C #, it will be apparent to those skilled in the art that various languages and syntax can be used to implement the notification mechanism. For any such implementation, an interface is specified for use by each data item. Each data item inherits this interface in order to implement dynamic updates.

public interface IPropertyChange

{

event PropertyChangedEventHandler PropertyChanged;

}

Then the event handler and its arguments are specified.

public delegate void PropertyChangedEventHandler (object sender,

PropertyChangedEventArgs e);

public class PropertyChangedEventArgs: EventArgs

{

public virtual string PropertyName {get;}

}.

The PropertyChangedEventArgs class contains a single read-only property called PropertyName, which is of the string type. The PropertyName property contains the name of the property that has changed. Then, each source data element implements this interface by invoking the PropertyChanged delegate whenever one of its properties changes. The following is an illustrative example implementation of a source object (eg, data element 232) according to an embodiment of a notification mechanism.

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));

}

}.

According to the above illustrative code, the 'set' method for the 'foo' property determines whether the new value is different from the old value. If the values differ, a handler is called. Reflection is done to get PropertyInfo. According to a further refinement, the binding machine can cache the type of property after it is obtained by reflection. Thus, reflection is carried out once, and not every time a notification is received for a property. According to another improvement, an empty string can be passed in the arguments to signal that all bindings to each of the data values of the data item should be updated. This can occur when the source object does not have information about which properties have changed, and therefore it is advisable to update each binding. After the binding machine receives a notification of a change in the value of the source data, processing proceeds to decision block 314.

Decision step 314 indicates determining whether a transformation for the binding is specified in the binding associated with the changed value of the source data. If no transformation is specified in the binding, then processing proceeds to step 318. If, however, a transformation is specified in the binding, processing proceeds to step 316.

Step 316 indicates the execution of the transformation specified in the binding. In one embodiment, converter 268 is an object as described below:

public interface IDataTransformer

{

public object Transform (object o, DynamicProperty dp,

CultureInfo c) {;}

}.

For the above interface, “o” indicates the source value, “dp” indicates the target dynamic property, and “c” indicates the culture to use during the conversion. The Transform () method converts the “o” value of the source into an object suitable for assigning to the dynamic property of the “dp” type. The Transform () method is called when the data value from the binding source is propagated to the target property. If the Transform () method returns null, then the binding machine is instructed to stop the spread of values.

The converter can also be used to control other properties of the PI, for example, width, height, font, location (x, y), etc. based on the corresponding source data value specified in the binding. Converters provide the ability to implement logic on data values in order to display data in several ways. According to a further improvement, a culture can be applied during the conversion as indicated in the binding. Processing then proceeds to step 318.

Step 318 denotes updating the target property. In one embodiment, the property machine assigns a value to the target property. In addition, the target property can be marked as having a new value. Processing may then proceed to block 312 to track the next property change notification associated with the binding. When the application terminates, or the binding otherwise terminates, processing ends.

As noted above, after step 308, the processing may go along the second path. Thus, after step 308, the processing proceeds to decision step 330. According to the above with respect to decision block 310, the logic in the binding machine does not always check the “binding type” on the decision block 310, therefore, if the binding machine does not receive an instruction to track notifications about the creation of the binding, the process does not go the second way. However, to simplify the description of the process, a decision-making phase is shown, which reflects the “type of binding”. Thus, decision block 330 indicates whether the binding is “two-way” as the “binding type”. As previously discussed, two-way binding allows you to propagate changes in the target property to the value of the source data. If the “binding type” for the binding does not have a “two-way” value, then the processing ends. If the binding has a two-way binding type, then processing proceeds to block 332.

At block 332, the binding machine detects certain actions that trigger updating the source data value. In the case of a start, processing proceeds to decision block 334.

Step 334 of the decision indicates the determination of whether the binding specified inverse transformation for the binding. If the binding does not specify an inverse transformation, then processing proceeds to step 338. If the binding specifies an inverse transformation, processing proceeds to step 336.

Step 336 denotes applying the inverse transform to the source property. In one embodiment, the inverter is the following object:

public interface IDataTransformer

{

public object InverseTransform (object o, PropertyInfo

pinfo.CultureInfo c) {;}

}.

For the above interface, “o” indicates the value of the source, “c” indicates the culture to use during the conversion, and “pinfo” indicates the PropertyInfo of the target property. The InverseTransform () method converts the value “o” of the source into an object suitable for assigning type information to the property. This method is called when a value is passed from the target to the source. If the InverseTransform () method returns null, then the binding machine does not pass the value. After performing InverseTransform, processing proceeds to block 338.

Step 338 denotes updating the source property in accordance with the “update type”. As described above, the "type of update" can have the meanings of "immediately", "when the focus is lost", "explicitly" and others. After updating the source property, processing ends.

In FIG. 4 illustrates several illustrative binding tools. Creation tool 400-410 creates a binding through pegging. Creation tool 412 creates a binding through code. The illustrative means shown in FIG. 4 are not the only ones possible. You can use other tools (syntax), without going beyond the scope of the present invention.

Creation tool 400 contains a DataContext name / value pair [data context] (hereinafter referred to as DataContext 422) and Id [identifier] name / value pair (hereinafter referred to as Id 420) for element 424. Since author 400 also contains DataContext 422, Id 420 is optional. Id 420 is needed when it is desirable to refer to an explicit source, for example, using ElementSource in markup or IdObjectReg in code. Both of these use cases are described below. DataContext 422 is a dynamic property defined (defined) on an element (e.g., element 424). The value associated with the DataContext 422 represents the default source data element and is an inherited property. The binding machine queries the DataContext 422 and uses the DataContext 422 when creating the 424 element and descendant elements (for example, the 426 Button [button]). The binding machine also tracks changes to the DataContext 422, which accordingly triggers the update. Thus, although not required, the DataContext 422 provides a convenient mechanism for setting the scope for all properties associated with a common data item. Descendant elements can have their own DataContext, which will take precedence over the DataContext 422 of the parent element. A binding can replace DataContext 422, providing a Source that is not null, described below in relation to the means of creation 402.

The Button element 426 is illustrated with a target property (e.g., Button.Text 428). According to the present invention, upon encountering “Data: Bind”, the binding machine recognizes that the binding has been set. Subsequent name / value pairs set the binding properties 260-272 indicated in FIG. 2. It will be apparent to those skilled in the art that the “Data: Bind” element for signaling a binding is arbitrarily selected, and any number of elements can be used without departing from the scope of the present invention. Creation tool 400 presents an advanced markup format.

Creation tool 402 presents a compact layout format. The PI property (for example, Button Text) is presented in a more compact form. Again, “Data: Bind” is used as a signal to the binding machine that the binding follows. In addition, the name / value pairs following Data: Bind correspond to the desired properties 260-272 described above for the binding object 250 in FIG. 2. For example, the ElementSource name / value pair (hereinafter referred to as ElementSource 434) corresponds to source 266.

The markup language has two methods for setting the source property: ElementSource and DataSource. If none of them is used, the source is set to null by default, which instructs the binding machine to obtain the value of the DataContext property of the element after creation and use this value as the source object.

When the authoring tool (for example, authoring tool 402) defines an ElementSource, the binding machine finds the element whose ID is specified by the ElementSource property. Then, the DataContext of this element is used as the source object. You can use relative path names to specify the data source, for example, / Parent / Parent and / Previous / Previous. When the binding machine encounters / Parent, it searches for the element that is the parent of the current element within the hierarchy of objects. For example, if the item is the customer’s job, then by specifying / Parent, you can instruct the binding machine to search for the item that matches the customer of the current job. Setting / Parent is useful in cases of a nested repeater when it is desirable to use values from an external repeater within the internal repeater. The / Previous task instructs the binding machine to look for an element preceding the current element in accordance with the “repeater”. Setting / Previous is useful when it is desirable to refer not only to the current element, but also to the element with the number “current-n”, for example, in edge graphs, etc. According to the present invention, sequential / Previous and / Parent can be used.

In another embodiment, the markup may specify a DataSource. When a DataSource is specified, the binding machine accepts the resource ID for the "resource". If the "resource" detects a data property, then the binding machine sets the "source" of binding to the object returned by the data property of the DataSource resource. Otherwise, the binding machine sets the binding source to the resource object itself.

It will be apparent to those skilled in the art that there are various ways in which properties 260-272 can be expressed using the markup language of documents, therefore, the manner in which each of these other properties can be expressed using the markup language of documents is not described in more detail.

The following three creation tools 404-410 provide illustrative examples related to the type of elements that allow the present invention to be linked. Creation tool 404 illustrates support for binding to sub-properties and indexers. Creation tool 404 corresponds to a binding written in C # as di.a.b [3] .c, where di is the corresponding data item. While the data element, the class that implements di.a, the class that implements di.ab, and the class that implements di.ab [3] .c, support the notification mechanism of the present invention (for example, IPropertyChange) and notify about a change in their properties , the binding specified using the creation tool 404 instructs the binding machine to automatically update the associated property (eg, the target property) to reflect changes in the value of the source data.

Creation tool 406 illustrates data collection binding support. The binding machine automatically uses the current collection entry at each level (where, a, b, and c represent different levels). For example, if di.a is of type IDataCollection, then, to select property “b”, the binding uses the current record in the collection. Thus, whenever the current record is changed, the binding machine automatically updates the values associated with the data collection.

Creation tool 408 illustrates XML node binding support. The path 260 to the value is provided using the xpath expression, for example, “/ Customer / Order [@ OrderID = 10] / Amount” shown in FIG. 4. Creation tool 410 illustrates binding to ADO data tables. For this implementation, the path 260 to the value is provided as the field name for a particular row, for example, “OrderID” shown in FIG. four.

Creation tool 412 creates bindings programmatically. The developer provides an object reference (objectref) to the object that the binding should use as a source data element. The program operators shown in creation tool 412 create a binding that behaves the same way as illustrated by creation tool 410. The SetBinding method has a number of more elaborate options whereby a programmer can set any of the binding properties discussed above. In the simple example above, the DataContext of the button is used as the source object. The following program statements create a one-way binding in which a specific object (known as a duty cycle) is used as a source:

Object source = ... some arbitrary object ...;

Binding SetBinding (myButton, Element.BackgroundProperty,

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

In the following code example, one implementation of managing a user interface property using data through the binding mechanism of the present invention is shown. In this example, the data value (for example, myInteger) and the PI property (for example, TextContent) are activated as a binding. In addition, a transformation is specified for this binding (for example, 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;

}

}.

Thus, the present invention provides a mechanism for associating a source data value with a target property, allowing the user interface and logic coding changes to be decoupled. Thus, the present invention allows developers to easily modify and modernize the user interface without having to change the underlying application logic.

The foregoing description of the invention, examples and data provide a complete description of the production and use of the composition of the invention. Since multiple embodiments of the invention are possible within the spirit and scope of the invention, the invention is defined by the claims below.

Claims (25)

1. A computer system for managing user interface properties using data, containing
processor and
memory allocated to a plurality of computer-executable application instructions loaded into memory for execution by a processor, the computer-executing instructions implementing a method comprising the steps of
creating a binding associating a user interface property with a data source data value, and a binding specification describing the association, the value being manipulated through part of the application logic,
create a binding object that is associated with the binding, which contains binding properties, containing: a path indicating the method by which the data source data values are found, a binding type defining a binding type that contains the type of one-way binding used to bind the data source data value with non-editable target property of the user interface, the type of two-way binding used to bind the data source data value with the editable target property of the user Yale interface update type, which defines - when the update must take place to the desired properties of the user interface, and culture property that specifies the rules for converting the source data value of the data; and
after receiving from the data source the code of the system level of the computing environment, notifications of a change in the data value in the data source automatically reflect this change in the user interface property by means of the user interface part of the application using the specification of the binding in response to the instructions from the system level code, the notification being mentioned taken based on the selected binding type. 2. The computer system according to claim 1, characterized in that it further comprises applying the conversion to the data value in the data source in a format acceptable for the user interface property, before making this change in the user interface property. 3. The computer system according to claim 1, characterized in that the creation of the binding includes setting the type of binding to perform the binding. 4. The computer system according to claim 3, characterized in that the type of binding includes such a type of binding, according to which the user interface property is updated based on the value of the source data when the binding is activated. 5. The computer system according to claim 3, characterized in that the type of binding includes a type of binding, according to which the user interface property is updated when the value of the source data changes. 6. The computer system according to claim 1, characterized in that it further comprises updating the data value in the data source after the user changes the properties of the user interface using the user interface. 7. The computer system according to claim 6, characterized in that the data value in the source is updated asynchronously almost immediately after changing the user interface property. 8. The computer system according to claim 6, characterized in that the data value in the data source is updated asynchronously when the focus is lost on the user interface property. 9. The computer system according to claim 6, characterized in that the data value in the data source is updated explicitly by the application. 10. The computer system according to claim 1, characterized in that the creation of the binding is set using program code. 11. The computer system according to claim 1, characterized in that the creation of the binding is set using a markup language. 12. A computer-readable medium having computer-executable instructions for managing user interface properties using data from a data source containing
part of the logic in the application for manipulating the value of the data in the data source,
part of the user interface as part of the application, and this part of the user interface is responsible for displaying the properties of the user interface on the screen, while the said part of the user interface is independent of the logic part, and
at least one binding associating a user interface property with a data value in the data source, and a corresponding binding specification describing the association, so that it is possible to notify the system level code of a change, by a part of the logic, of the data value in the data source, so that system level code could prescribe portions of a user interface to reflect a change in a user interface property, said at least one binding being associated with a binding object that contains binding properties, comprising: a path indicating a method by which data source data values are found, a binding type that defines a binding type that contains a one-way binding type used to bind said data source data value with an uneditable target property user interface, a two-way binding type used to bind a data source data value with an editable user interface target property , The type of update, which sets - when they should take place upgrade to the target properties of the user interface, and cultural property, which sets the rules for the conversion of values data source. 13. The computer-readable medium of claim 12, wherein the binding specification is software defined. 14. The computer-readable medium of claim 12, wherein the binding specification is specified using a markup language. 15. The computer-readable medium of claim 12, wherein the binding specification identifies a source data element, a path to a data value in a source data element, a user interface element corresponding to said source data element, and a user interface property corresponding to said user interface element . 16. The computer-readable medium of claim 15, wherein the binding specification further identifies the transformation applied to the data value in the data source to convert it to a format acceptable for the user interface property before the change is made to the user interface property . 17. The computer-readable medium of claim 15, wherein the binding specification further identifies the type of binding. 18. The computer-readable medium of claim 17, wherein the type of binding includes a type of binding, according to which the user interface property is updated based on the data value when the binding is activated. 19. The computer-readable medium of claim 17, wherein the type of binding includes a type of binding in accordance with which the user interface property is updated when the data value changes. 20. The computer-readable medium of claim 15, wherein the binding specification further specifies that the data value in the data source should be updated when the user interface property undergoes a change from the user. 21. The computer-readable medium of claim 20, wherein the data value is updated asynchronously almost immediately after changing the user interface. 22. Machine-readable medium according to claim 20, characterized in that the data value is updated asynchronously when the focus is lost on the user interface property. 23. The computer-readable medium of claim 12, wherein the data value in the data source is updated explicitly by the application. 24. Machine-readable medium according to claim 12, characterized in that it further comprises creating another binding linking said property of the user interface with a different data value in the data source other than the first data value. 25. The computer-readable medium of claim 12, wherein the data source is specified by means of XPath in XML, or a column in an ActiveX data object (ADO), or reflection.

Images