JP5010625B2 - Recording medium and system storing program for controlling user interface property by data - Google Patents

Description

  The present invention relates to a recording medium and a system storing a program for controlling user interface properties by data.

  How the information is presented to the user determines how much the user can understand and grasp the information. In computer display devices, it is standard practice to add emphasis to information by using colors, font styles, and the like. By adding such emphasis, the user can easily grasp the importance of information. The code that handles the display of information (user interface) and the code that executes application logic on the information are usually closely tied. For example, the logic directly assigns data to user interface properties (eg, color, font, position, size). Therefore, if the user interface changes, the logic must change. For example, in the case of a text box, the user interface code is listened to determine if the text has changed, and there has been a change. If so, the user interface code validates whether the changed text is valid, and then displays the changed text. Because of this close nature of the user interface and logic, the code is very fragile. The maintenance of this fragile code is very expensive and time consuming.

  The present invention provides a recording medium and system storing a program for controlling user interface properties by data.

  The present invention provides a mechanism for associating data with a user interface, thereby decoupling the user interface and data along with its application logic. The present invention allows user interface designers and application authors who write application logic to work independently. Neither designers nor authors need to understand each other's code or affect other's code development. In the present invention, it is also possible to make changes to the user interface quite simply. For example, if a new, more user-friendly user interface platform becomes available or the user interface designer wants to change the look of the application The designer does not need to change the application logic. Furthermore, the mechanism for associating data with the user interface is dynamic. Thereby, the data change can be automatically reflected in the presentation. Furthermore, the data can be automatically updated by the input made by the user via the user interface. Using the present invention, it is possible to associate not only the data display aspect (eg, text) of the user interface, but also the visual aspect (eg, background, font size, etc.) Allows descriptive, highly visual and flexible presentation of data. For example, when the stock price is rising, negative numbers can be displayed in red, or arrows can be displayed pointing up.

  Therefore, according to the present invention, an application is divided into independent parts, a logic portion, and UI portion. In the logic part, data values in the application are manipulated. The UI part is responsible for the presentation of the data. A relationship between a UI property and a data value is described by a binding specification. The binding specification is system level to determine how to be notified when a change occurs in the data value and how to instruct the UI part to reflect that change in the UI properties. Used by system level code. The binding specification includes a source data item, a path to the data value in the source data item, a target UI element, and a UI property (UI for the target UI element). property on the target element). A binding is specified using code or a markup language.

FIG. 6 illustrates an example of a computing device that can be used in an embodiment of the present invention. FIG. 6 is a functional block diagram illustrating one embodiment for controlling user interface properties with data in accordance with the present invention. 5 is a logic flow diagram illustrating a process for binding user interface properties to data values according to one embodiment of the invention. FIG. 6 illustrates a plurality of example syntaxes that associate user interface properties with data in accordance with the present invention.

  The present invention is directed to a system and method for controlling a user interface with data. The present invention separates the user interface and application logic by providing a mechanism for associating data with the user interface. As detailed below, this separation between the user interface and the data, along with the associated logic, allows various groups of developers to interact with the user interface and without affecting the other groups' code development. Both logic can be handled. Further, as described in detail below, the present invention implements a system and mechanism for automatically transferring data from a data source to a user interface and from the user interface to the data source. Throughout the following description, the term “databinding” refers to processes such as associating a data value with a UI property, transferring and updating the data value.

Computing Environment FIG. 1 illustrates an example of a computing device that can be used in practicing the present invention. With reference to FIG. 1, in a very basic configuration, computing device 100 typically includes at least one processing unit 102 and system memory 104. Depending on the exact configuration and type of computing device 100, system memory 104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. The system memory 104 typically stores an operating system 105, one or more program modules 106, and may include program data 107. Examples of the program module 106 include a browser application, a financial management application, and a word processor. The basic configuration is illustrated in FIG. 1 by the components within dotted line 108.

  The computing device 100 may add further features or functions. For example, the computing device 100 may include additional data storage devices (removable and / or non-removable) such as magnetic disks, optical disks, or tapes. Such additional storage is illustrated in FIG. 1 by removable storage 109 and non-removable storage 110. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in methods or techniques for storing information such as computer readable instructions, data structures, program modules, or other data. it can. System memory 104, removable storage 109, and non-removable storage 110 are all examples of computer storage media. Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital multipurpose disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage There are devices, or other media that can be used to store information of interest and that can be accessed by computing device 100. Any such computer storage media can be part of device 100. Further, the computing device 100 may include an input device 112 such as a keyboard, mouse, pen, voice input device, touch input device, or the like. An output device 114 such as a display device, a speaker, or a printer may be provided. These devices are well known in the art and need not be described in further detail here.

  The computing device 100 may also include a communication connection 116 that the device uses to communicate with other devices 118, such as over a network. Communication connection 116 is an example of a communication medium. Communication media typically can be implemented with computer readable instructions, data structures, program modules, or other data via a modulated data signal such as a carrier wave or other transport mechanism and includes information delivery media. . The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example, communication media include wired media such as a wired network or direct wire connection, and wireless media such as acoustic, RF, infrared, and other wireless media. The term computer readable media as used herein includes both storage media and communication media.

Example FIG. 2 is a functional block diagram illustrating one embodiment of a system 200 for controlling user interface properties with data in accordance with the present invention. System 200 includes an application 202, a platform 220, and a data source 230. The application 202 can be one of a plurality of applications 106 on the computing device 100 shown in FIG. Application 202 includes code (hereinafter referred to as logic 204) for manipulating data values (eg, source data value 238). In general, the logic 204 performs validation on the data value and updates the data value. The data value (eg, data value 238) represents the content of the property (ie, data source property) of the data item (eg, data item 232). Data item 232 is located in a data source (eg, data source 230). Each data source 230 can include a plurality of data items, each data item having one or more properties, and the source data value is stored in the properties. The logic 203 can manipulate data values from multiple data sources. Data sources can include XML documents, objects, datasets, and the like. As will be described in detail later, each property of the data item can be used to control a user interface (UI).

  The application 202 further includes code for displaying information (hereinafter referred to as the user interface 206). User interface 206 includes a plurality of user interface elements (eg, user interface element 208). Each user interface element 208 includes one or more properties (eg, UI properties 210 and 212) such as displayed text, color, font, position, size, and the like. Next, as described in detail below, these UI properties 210 and 212 are associated with one or more of the data values 238 and 242 in accordance with the present invention. In general, the association is performed via a binding engine 224 in the platform 220. The platform 220 represents system layer services such as an operating system and a virtual engine. The platform 220 further includes a property engine 222 that holds hierarchical information related to the data values 234 and 242 and serves to update the associated properties with the data values. Even though the binding engine 224 and the property engine 222 are shown as separate components, those skilled in the art will appreciate that the functionality provided for each can be contained within a single component without departing from the invention. Will understand.

  The association (that is, binding) between the data values 238 and 242 and the UI properties 210 and 212 is represented by a dotted line from the data value to the UI property in FIG. 2 (hereinafter referred to as bindings 226 and 228). In the following description, the term “data value” can be rephrased as the term “source data value”. Similarly, the term UI property can be rephrased as the term “target property”. Using these bindings 226 and 228, dynamic properties (ie, target properties) can be automatically set from data values (ie, source data values) such as properties of any object. These bindings are dynamic and target properties that are bound to reflect changes in the source data value are automatically updated.

  In order to realize this automatic update function, the present invention further provides a notification mechanism (for example, in FIG. 2, notifiers 236 and 240 and notifier to platform 220). Up to the arrow). Each data item 232 and 234 has a corresponding notifier 236 and 240, respectively. The notification mechanism is responsible for notifying the system that the source data value has changed and that the data value can be propagated to the target property (ie, UI property).

  When bindings 226 and 228 are created through markup, code, etc., binding engine 224 creates binding objects (eg, binding objects 250 and 252) associated with the binding. For example, the binding object 252 can represent a binding 228 within the binding engine 224. Each binding object includes a plurality of properties (for example, binding properties 260 to 272). These binding properties 260 to 272 can be set by a program. The following discussion describes each of these properties, and FIG. 4 shows an example code that activates a binding that specifies some of those properties.

  One of the binding properties (hereinafter referred to as path 260) identifies the way to identify the source data value (via the source object). The path 260 can refer to a property, sub-property or indexer on the source object, a column in ADO (ActiveX Data Objects), an XPath on XML, or the like. Alternatively, reflection or ADO path can be referred to by path.

  The types of bindings 226 and 228 are defined by another binding property (hereinafter referred to as a bind type 262). In one embodiment, bind types include one-way (oneWay), two-way (twoWay), and one-time (oneTime). As shown, the binding 226 represents a two-way binding, and the binding 228 represents a one-way binding. One of these binding types is set as the default. In one embodiment, bi-directional binding is set as the default binding type.

  If the bind type 262 is specified as one-way (oneWay), this informs the binding engine 224 to update the target property (eg, UI property 210) whenever there is a change in the associated source data value. . The OneWay bind type is used when data values are bound to non-editable UI properties such as text color and text background color. Using the unidirectional bind type avoids the overhead of the bidirectional bind type, as described below. Thus, the reduction in overhead is most noticeable when listening to changes in UI properties related to layout contents. For these UI properties, the dynamic properties of each of the UI property children must be listened for UI property changes. The unidirectional bind type may also be useful if the UI property changes are merely to show other display details.

  If the bind type 262 is specified as bidirectional, this informs the binding engine 224 to update the target property each time the source data value changes and vice versa. Bidirectional binding is particularly useful when binding data to an edit box when changes made by the user in the edit box need to be propagated to the source data value. Another scenario for bidirectional binding is when other applications are responsible for the source data field and the changes are reflected in the edit box.

  If the bind type 262 is specified as only once, this informs the binding engine 224 to update the target property once and exit immediately even if the associated source data value has changed. . The one-time bind type (oneTime bindtype) is used when some target properties need to be initialized with some value from the source field and the data context is not known in advance. In addition, the one-time bind type is useful for read-only use without changing the source data value. If the data source does not support the property notification mechanism of the present invention (eg, IPropertyChange interface), the target property specified as unidirectional is updated as if the binding specified only once as the bind type. Is done.

Another type of binding property (hereinafter referred to as update type 264) defines the type of update for the case where the bind type 262 specifies bidirectional. Usually, a bi-directional binding listens for changes in target properties and propagates the changes back to the source data value. This process is said to update the source. It is usually desirable to update whenever the target property changes. However, in some situations, updating every time a key is pressed results in a useless cycle, and the user has no chance to correct an input error or the like. The update type (updatetype) 264 allows the user to specify when to perform the update. In one embodiment, update type 264 may specify Immediate, OnLostFocus, and Explicit. When Immediate is specified, the binding engine updates the source data value every time the target property is changed. Specifying OnLostFocus causes the binding engine to update the source data value after the target element loses keyboard focus. When Explicit is specified, the binding engine updates the source data value only when the application explicitly requests an update. Usually, this explicit request is performed via a method. Even though this method can be called to set the update type 264, this method is used when the update type is set to Explicit. One example method is shown below.
Binding.GetBinding (myElement, myProperty) .Update ();

  Another of the binding properties (hereinafter referred to as source 266) identifies the source data item for the binding. Briefly, as shown and described in FIG. 4, source 266 can be set programmatically or using markup. For the program, the developer prepares an objectref to the object that must be used as the source data item in the binding. In brief, as described in detail with respect to FIG. 4, there are various ways to set source properties in markup.

  Another of the binding properties (hereinafter referred to as transformer 268) accepts a class reference. The class reference is <Namespace>. It can be specified using <Class>, <Assembly>. The identified class reference is invoked by the binding engine 224 to transform the source data value into a form that is accepted by the target property. The method in the class reference calls this transform, which is represented as transform 244 in FIG. The class reference can also specify an inverse transform (not shown) that transforms the target property into a form that is accepted by the source data value. The transform 244 can provide UI meaning or can be a custom type converter.

  Another of the binding properties (hereinafter referred to as culture 270) defines how the source data value should be processed before / after transforming the source data value. Culture 270 works with transformer 268 to allow developers to specify rules that transform source data values. For example, in culture, a specific format for several values, dates, etc. can be specified. In one embodiment, culture 270 accepts a value of CultureInfo type. Developers have the option to use the rules specified by culture 270 when performing the transform.

Another of the binding properties (hereinafter referred to as the bind flag 272) has a mechanism for receiving an event and receiving an event notifying the transfer of data. Although the above method of data binding is asynchronous, the bind flag 272 allows the developer to know when the target is updated with a new value. In order to use this mechanism, the bind flag 272 is set to “NotifyOnTransfer”. Then use the usual method to register a handler for the event. An example of the use of such a mechanism is shown below.

Public static void main ()
{
// add a handler
elem.AddAttachedHandler (Binding.DataTranferEvent,
new DataTranferEventHandler (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";
}.

  As shown in the code example above, when the OnDataTransfer event occurs, the developer is notified that the dynamic property has been updated. Therefore, the developer can use the target value for further processing.

  FIG. 3 is a logic flow diagram illustrating a binding mechanism according to one embodiment of the invention. In general, the binding mechanism performs an action to set up the binding (blocks 302-306), and then performs an action related to changing the target property or source data value as specified in the binding (blocks 310-306). 338). Processing continues at block 302.

  In block 302, a binding object is created based on the arguments specified at creation time. In short, each property for the binding object 252 (ie, the properties 260-272 shown in FIG. 2) can be specified as an argument at the time of creation. Bindings can be created through markup, programmatically, and in a similar manner. FIG. 4 shows a syntax example for creating a binding and specifying the properties 260 to 272. Each creation method identifies the source data item, the path to the data value in the source data item, the target UI element, and the target dynamic property on the UI element. Although not shown in the current flow diagram, the properties of the binding object can also be modified dynamically at runtime, such as using an application programming interface (API). The process proceeds to step 306.

  In block 304, the binding is activated. In one embodiment, the binding can be activated automatically after notifying that the binding has sufficient context, such as allowing the binding engine to have the source object present and the target element ready to be displayed. It is. The binding engine is responsible for recognizing binding activation. Processing continues at block 304.

  At block 306, the value of the identified source property is found. In one embodiment, reflection is used to find value. Reflection is a common mechanism that a caller uses to obtain information about a requested object. This information includes supported objects, public properties, etc. In other embodiments, if the data item is a collection, the binding engine performs a heuristic many times to determine whether it is using the current record or the data object (collection) itself. The first heuristic is applied when the binding references a property or indexer. In such a situation, the corresponding property or indexer on the collection object is used if such a property or indexer exists. Apart from that, the current record of the collection is used as a data item. If the property or indexer does not exist, other heuristics are applied. In such a situation, 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 block 308, if the transform identifies a transform (block 307), the transform is applied to the value. The application of the transform is described in detail with respect to block 316 below. Processing continues at block 308.

  At block 308, the found value is assigned to the target property. In one embodiment, a value can be assigned by a property engine that is responsible for maintaining a hierarchy of properties. In other embodiments, prior to assigning a value to the target property, it is possible to invoke the transform specified when creating the binding to transform the value. In other refinements, the property engine can mark a property as having a new value. After blocks 302-308 are executed, the binding engine is ready to update the target properties and source data values as needed. In general, the binding mechanism is asynchronous.

  Thus, from block 308, the process follows two asynchronous paths. The first path (blocks 310-318) is associated with updating the target property, and the second path (blocks 330-338) is associated with updating the source data value. Each of these paths is described below. First, it shows the path that has the role of updating the target property.

  In a decision block 310, the binding engine determines whether the binding type is specified as only once in the binding associated with the source data value and the target property. If the bind type is only once, the process for the bind is complete and the process proceeds to the end. One skilled in the art will understand that if the bind type is only once, the binding engine will not listen for source property change events. Thus, in actual operation, the logic within the binding engine does not necessarily perform a check as indicated by block 310. Further, if the data item does not implement IPropertyChange, the process is complete. However, if the bind type is not only once, processing continues at block 312.

  At block 312, the binding engine listens for notifications associated with the binding. The present invention implements a notification mechanism because the target is not directly updated using the source data value in data binding. Notification mechanisms such as property change notifications and collection view “CurrentChanged” notifications are known in the art and need no further explanation here. Different actions can trigger notifications such as data value changes, page navigation, shutdown, and changes to records of interest in the data collection. Since the present invention triggers an update when there is a change in a record of interest in the data collection, the present invention provides a convenient mechanism for further separating the user interface and logic. For example, in accordance with the present invention, the developer need only write code in the logic that specifies how to make changes to the next record of interest in the data collection. When the change is performed, the binding engine updates the user interface based on the already identified binding according to the present invention. As already mentioned, this separation of user interface and logic makes the application more robust and easier to maintain than when the user interface and logic are interrelated.

The following code is an example of a notification mechanism. The code examples created below are written in C #, but those skilled in the art will understand that various languages and syntaxes can be used to implement the notification mechanism. Let's go. For such implementations, an interface is defined for use with each data item. Each data item inherits this interface to perform a dynamic update.

Public interface IPropertyChange
{
event PropertyChangedEventHandler PropertyChanged;
}.

Next, an event handler and its arguments are defined.

public delegate void PropertyChangedEventHandler (object sender, PropertyChangedEventArgs e);

public class PropertyChangedEventArgs: EventArgs
{
public virtual string PropertyName {get;}
}.

The class PropertyChangedEventArgs contains one read-only property named PropertyName with a type string. The PropertyName property contains the name for the changed property. Next, each source data item implements this interface by calling the PropertyChanged delegate whenever one of its properties changes. The following is an example of implementing a source object (eg, data item 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));
}
}.

  As shown in the code example above, the “set” method of the “foo” property determines whether the new value is different from the old value. If the values are different, the handler is called. Reflection is performed to get PropertyInfo. In other refinements, the binding engine can cache property types obtained through reflection. Thus, reflection is performed once and not every time a notification is received about a property. In other refinements, an empty string can be passed in as an argument to signal that all bindings for each data value of the data item should be updated. This can be done if the source object is not sure which properties have changed and each binding needs to be updated. When the binding engine receives a notification that the data source value has changed, processing proceeds to decision block 314.

  At decision block 314, it is determined whether the binding associated with the changed source data value has identified a transform for the binding. If the binding does not specify a transform, processing continues at block 318. However, if the binding specifies a transform, processing continues at block 316.

At block 316, the transform specified in the binding is executed. In one embodiment, transformer 268 is an object as described below.

Public interface IDataTransformer
{
Public object Transform (object o, DynamicProperty dp, CultureInfo c) {;}
}.

  In the above interface, o represents the source value, dp represents the dynamic property of the target, and c represents the culture used for transformation. The Transform () method transforms the source value o into an object suitable for assigning to a dynamic property of type dp. The Transform () method is called when the data value is propagated from the binding source to the target property. When the Transform () method returns a null value, the binding engine is notified that value propagation is to be stopped.

  The transformer can also be used to control other UI properties such as width, height, font, position (x, y) based on the associated source data value specified in the binding. Transformers can perform logic on data values to display data in multiple ways. In other refinements, the culture can also be applied at the time of transformation as specified in the binding. Processing continues at block 318.

  At block 318, the target property is updated. In one embodiment, the property engine assigns a value to the target property. In addition, the target property can be marked as having a new value. Processing then continues to block 312 to listen for the next property change notification associated with the binding. When the application terminates or the binding is aborted by some other means, processing proceeds to the end.

  As described above, processing can continue from block 308 to a second pass. Thus, from block 308, processing continues to decision block 330. As described above, with respect to decision block 310, the logic in the binding engine cannot necessarily perform a binding type check at decision block 310, but rather the binding engine listens for notifications when a binding is created. The process does not flow in the second pass. However, to clarify the flow description, a decision block reflecting the bind type is shown. Accordingly, at decision block 330, a determination is made whether the binding has been identified as a two-way binding type. As already mentioned, bi-directionally, target property changes can be propagated to the source data value. If the binding is not specified as a bidirectional bind type, processing proceeds to the end. However, if the binding specifies as a bidirectional bind type, processing continues to block 332.

  At block 332, the binding engine recognizes several actions that trigger an update of the source data value. When the trigger occurs, processing continues at decision block 334.

  At decision block 334, a determination is made as to whether the binding has identified an inverse transform for the binding. If the binding does not specify a reverse transform, processing continues at block 338. However, if the binding identifies a reverse transform, processing continues at block 336.

At block 336, the inverse transform is applied to the source property. In one embodiment, the inverse transformer is an object as described below.

Public interface IDataTransformer
{
Public object InverseTransform (object o, PropertyInfo pinfo, CultureInfo c) {;}
}.

  In the above interface, o represents the source value, c represents the culture to be used at the time of transformation, and pinfo represents the target property PropertyInfo. The InverseTransform () method transforms the source value o into an object suitable for assigning to a property of type info. This method is called when propagating value from the binding target to the source. If the InverseTransform () method returns a null value, the binding engine does not propagate the value. Once InverseTransform is executed, processing continues to decision block 338.

  At block 338, the source property is updated according to the update type. As described above, the update type may be triggered by immediate, loss of focus, explicit, and others. After the source property is updated, the process proceeds to end.

  FIG. 4 shows some examples of creating bindings. In creation means 400-410, the binding is created through markup. The creation unit 410 creates a binding through code. The example means shown in FIG. 4 are not exhaustive. Other means (syntax) can be used without departing from the scope of the present invention.

  The creation means 400 includes a DataContext name / value pair (hereinafter referred to as a DataContext 422) and an Id name / value pair (hereinafter referred to as an Id 420) for the element 424. Since the creation unit 400 further includes a DataContext 422, the Id 420 is not necessary. Id 420 is necessary when it is desirable to reference an explicit source, such as using ElementSource in markup or using IdObjectReg in code. Both of these applications will be described later. DataContext 422 is a dynamic property defined in an element (eg, element 424). The value associated with DataContext 422 represents the default source data item and is an inheritable property. The binding engine queries DataContext 422 and uses DataContext 422 when creating bindings for element 424 and descendant elements (eg, Button element 426). The binding engine also listens for changes in DataContext 422 and performs an update with that trigger. Thus, although not necessary, DataContext 422 provides a convenient mechanism for establishing a scope for all properties bound to a common data item. A descendant element can have its own DataContext, which overrides the parent element's DataContext 422. The binding can override DataContext 422 by providing a non-null source as described below with respect to creation means 402.

  Button element 426 is illustrated with a target property (eg Button. Text 428). In the present invention, when the binding engine finds “Data: Bind”, it recognizes that the binding is specified. The latter name / value pairs set binding properties 260-272 as specified in FIG. Those skilled in the art will understand that the term “Data: Bind” indicating binding is an arbitrary term, and any number of terms may be used without departing from the present invention. The creation means 400 represents a detailed markup format.

  The creation unit 402 represents a compact markup format. UI properties (eg Button Text) are represented in a more compact manner. Again, “Data: Bind” is used as a signal to inform the binding engine that what follows is binding. Further, the name / value pair and the following “Data: Bind” correspond to the desired properties 260-272 already described for the binding object 250 in FIG. For example, an ElementSource name / value pair (hereinafter referred to as ElementSource 434) corresponds to the source 266.

  In markup, there are two methods for setting a source property: ElementSource and DataSource. If none of these are used, the default value of the source is null, and after creation, the value of the DataContext property of the element is obtained and the binding engine is notified to use that value as the source object.

  When the ElementSource is specified by the creation means (for example, the creation means 402), the binding engine finds an element having the ID specified by the ElementSource property. The element DataContext is then used as the source object. Relative pathnames such as / Parent / Parent and / Previous / Previous can be used to identify the data source. When the binding engine finds / Parent, it looks for the element that is the parent of the current element with respect to the object hierarchy. For example, if the element is a customer order, specifying / Parent can inform the binding engine to look for the element corresponding to the customer for the current order. Specifying / Parent is useful for nested repeaters where it is desirable to use the value from the outer repeater that is within the scope of the inner repeater. When / Previous is specified, the binding engine looks for the element before the current element under Repeater. Specifying / Previous is useful when it is desirable to access the current n items in addition to the current item, such as a bar graph. The sequence / Previous and / Parent can be used according to the present invention.

  In other embodiments, the DataSource can be identified in the markup. If the DataSource is specified, the binding engine accepts the Resource ID of the Resource. When the Resource exposes a data property, the binding engine sets the source of the binding to the object returned by the data property of the DataSource resource. Otherwise, the binding engine sets the binding source to the resource object itself.

  One skilled in the art will appreciate that the properties 260-272 are expressed using a markup language, and thus this allows each of the other properties to be expressed using a markup language. It will not be described in detail here.

  The next three creation means 404-410 give examples regarding the types of items that can be bound in the present invention. The creation means 404 shows support for binding to sub-properties and indexers. The creation means 404 is di. a. b [3]. It corresponds to the binding written in C # like c, and di is a related data item. Data item, di. a class that implements a. a. a class that implements b, and di. a. b [3]. As long as the class that implements c supports the notification mechanism of the present invention (eg, IPropertyChange) and notifies when a property has changed, the binding specified using the creation means 404 will cause the binding engine to automatically Update bound properties (eg, target properties) to reflect changes in the source data value.

  Creation means 406 shows support for binding to a data collection. The binding engine automatically uses the current record of the collection at each level (a, b, and c represent different levels). For example, di. If a is an IDataCollection type, the binding uses the current record of the collection to fetch the “b” property. Thus, the binding engine automatically updates the value associated with the data collection whenever the current record changes.

  The creation means 408 indicates support for binding to an XML node. The path 260 to the value is given using an xpath expression such as “/ Customer / Order [@ OrderID = 10] / Amount)” as shown in FIG. The creation means 410 shows support for binding to the ADO data table. For this implementation, the path 260 to value is given as the field name for a particular row, such as “OrderD”, as shown in FIG.

The creation unit 410 creates a binding by a program. The developer provides an objectref to the object that must be used as the source data item in the binding. The statement of the program shown in the creation means 412 creates a binding with the same operation as exemplified by the creation means 410. The SetBinding method provides a number of more sophisticated modifications that can be used by programmers to specify the binding properties described above. In the simple example above, the button's DataContext is used as the source object. The following program statement creates a unidirectional binding that uses a specific object (known at runtime) as a source.

Object source = ... any arbitrary object ...;
Binding.SetBinding (myButton, Element.BackgroundProperty, "Color", BindType.OneWay, new ExplicitObjectRef (source));

The following code example illustrates one implementation for controlling user interface properties with data via the binding mechanism of the present invention. In this example, the data value (eg, myInteger) and UI property (eg, TextContent) are activated as bindings. In addition, a transform (eg, MyTransformer) is specified for this binding.

<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, as described, the present invention provides a mechanism for associating source data values with target properties such that user interface and logic coding changes are isolated. Thus, the present invention allows a developer to easily modify and enhance the user interface without modifying the basic logic of the application.

  The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention is defined by the appended claims.

Claims (16)

A computer-readable recording medium storing a computer-executable program comprising a user interface portion having user interface elements each including one or more user interface properties and a logic portion configured to manipulate source data values. The program is a binding object for binding that associates the user interface property of the user interface part with the source data value stored in the storage means, and specifies the source data value. Updates to the user interface properties, the path that contains the method, the binding type that defines the type of binding, and Creating a binding object having a binding property including an update type that identifies when it occurred and a culture property for identifying rules for transforming the source data value;
When said source data value is notified that have changed, on the basis of the binding object according to the source data value to reflect the changes to the user interface property, it is executed and step you update the user interface, and
The binding type is “unidirectional” used when the source data value is related to the user interface property that cannot be edited by the binding, or the binding to the user interface property that can edit the source data value. Including "bidirectional" used when relating by
The received notification is based on the binding type of the binding object related to the changed source data value.   The computer-readable recording medium of claim 1, wherein the source data value is transformed based on the culture property before the change is reflected in the user interface property. 3. The program according to claim 1, wherein the program causes the computer to execute a step of updating the source data value associated with the user interface property when the user interface property is changed. The computer-readable recording medium as described.   The computer-readable medium of claim 3, wherein the step of updating the source data value is performed asynchronously after the change of the user interface property.   The computer-readable medium of claim 3, wherein the step of updating the source data value is performed asynchronously after the focus on the user interface element is lost.   The computer-readable recording medium according to claim 1, wherein the binding is specified using a code.   The computer-readable recording medium according to claim 1, wherein the binding is specified using a markup language. The source data value is described from the storage unit, XPath on XML, to any one of claims 1 to 7, characterized in that it is identified through one of the ADO column and Reflection Computer-readable recording medium. A user interface portion having user interface elements each including one or more user interface properties;
A logic part configured to manipulate the source data value;
Storage means;
A binding object of a binding that associates a user interface property of the user interface part with a source data value stored in the storage means, including a path including a method for identifying the source data value, and a type of binding A binding object having a binding property including a binding type, an update type specifying when an update to the user interface property occurs, and a culture property for specifying a rule for transforming the source data value Means to create,
When receiving the notification that the source data value is changed, on the basis of the binding object according to the source data value to reflect the changes to the user interface property, and means you update the user interface,
The binding type is “unidirectional” used when the source data value is related to the user interface property that cannot be edited by the binding, or the binding to the user interface property that can edit the source data value. Including "bidirectional" used when relating by
The received notification is based on the binding type of the binding object related to the changed source data value. 10. The computer system of claim 9 , wherein the source data value is transformed based on the culture property before reflecting the change to the user interface property. The computer system according to claim 9 or 10 , further comprising means for updating the source data value associated with the user interface property when the user interface property is changed. The computer system according to claim 11 , wherein the means for updating the source data value is executed asynchronously after the change of the user interface property. The computer system of claim 11 , wherein the means for updating the source data value is performed asynchronously after focus on the user interface element is lost. The binding, the computer system according to any one of claims 13 claim 9, characterized in that it is identified using code. The computer system according to any one of claims 9 to 13 , wherein the binding is specified using a markup language. The source data value is described from the storage unit, in any one of claims 15 claim 9, characterized in that the specified XPath on XML, through one of the ADO column and Reflection Computer system.

Images