Patent Application
20080301185
Most layered applications contain validation logic that is dispersed across several layers of the application. For example, the validation logic may be dispersed in user interface and business logic layers. One solution to this is to have a shared library of validation functions. Whenever validation is needed in a layer, a function in the library is called from the appropriate layer. This model has problems with extending or changing the validation. For example, when an additional validation function is added, a developer must ensure that this function is invoked at every location where a change to the data may occur. If the developer misses a location, data may not be validated.
Briefly, aspects of the subject matter described herein relate to validating properties. In aspects, a property is associated with one or more validators. Each validator includes actions to take to determine whether a feature of the property is valid. Multiple validators may be executed for a single property. A group of validators may be identified by an identifier. In addition, properties may be grouped into collections which may be grouped into other collections and so on. Each collection may also be associated with one or more validators to validate properties within the collections.
This Summary is provided to briefly identify some aspects of the subject matter that is further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The phrase “subject matter described herein” refers to subject matter described in the Detailed Description unless the context clearly indicates otherwise. The term “aspects” should be read as “at least one aspect.” Identifying aspects of the subject matter described in the Detailed Description is not intended to identify key or essential features of the claimed subject matter.
The aspects described above and other aspects of the subject matter described herein are illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 110. Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any 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. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, discussed above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
As mentioned previously, an application may need validation logic to validate data. The data (sometimes referred to as a property or properties) to validate may be received in a variety of ways including a user interface, a collection of data included in an XML file, a database, a file, and the like, etc.
An application or other process may include a user interface 205 that includes some data input screens (e.g., data input screens 210-213) for entering or modifying data. For simplicity in presentation, the term “application” is sometimes used herein to refer to the entity that takes advantage of aspects of the subject matter described herein, but it should be understood that in alternative embodiments, other processes and/or components such as kernel-mode processes, operating system components, database management system components, file system components, installation tools, combinations of the above, threads of the above, and the like may employ aspects of the subject matter described herein.
The data input screens 210-213 may include one or more controls capable of receiving data. For example, an application may include text boxes, grid controls, tool bars, list box items, combo boxes, buttons, panels, menus, sub menus, and many other controls as will be readily recognized by those skilled in the art. These controls may be used to enter or modify data associated with a program. For example, an installation wizard may collect data in various data input screens. The wizard may then use this data to install or configure software package, for example.
As another example, a Web shopping cart interface may include several screens to gather information that is needed to bill and ship a product to a customer. A computer seller that allows a user to configure a computer system via a Web site before buying the computer system may have many screens for collecting data about what options (e.g., hardware components, software components, peripherals, and the like) that the user wants with the computer system.
Each screen may include data that relates to one or more properties. A property as used herein includes data that may be entered, changed, or otherwise manipulated via a user interface, a program, or otherwise. A property may also include data that is derived from the data above. A property may also include methods associated with the data.
Properties obtained from a control may be stored in a variable or other data structure in volatile or non-volatile memory. For example, referring to
A data structure such as the data structures 215-218 may comprise a collection of properties. In one embodiment, a data structure such as one of the data structures 215-218 may implemented as a dictionary object having key, property pairs. When the dictionary object is given a key associated with a property stored in the dictionary object, it returns the associated property.
An application developer may desire to constrain the properties to certain values. For example, in Internet addresses, a developer may desire to have a number between 0 and 255 inclusive for each of the parts of the address. For ages, a developer may desire to have a positive number. For strings, a developer may desire to constrain the string to a certain size or to include or exclude certain characters in the string, for example.
An example that many users are familiar with is that of entering or changing a password. In this case, to create a strong password, a developer may wish to constrain the password to strings greater than a certain length. In addition, the developer may also desire that the password include certain non-letter characters. Furthermore, the developer may desire that the password not have been used in the last fifteen password changes.
In accordance with aspects of the subject matter described herein, a property may be associated with one or more validators. A validator is a function that may include one or more programming steps that determine whether a feature of an associated property is valid. The term “feature” is used to indicate that while the property may be valid as far as the programming steps of the validator are concerned, that another validator may determine that the property is not valid. The term “feature” may include more than one characteristic of the property. If only one validator is associated with a property and the validator determines that the features it checks are valid, this is synonymous with the property being valid.
Sometimes below, it is indicated that a validator determines that a property is valid or invalid. It is to be understood that this means that as far as the validator is concerned, the property is valid. As indicated above, another validator may find that the property is invalid.
A validator may return, for example, a Boolean value that indicates that the property is valid or invalid. A validator may also include a list of problems with a property that is not valid. For the password example, this list of problems may include, for example, the password being too short, not including non-letter characters, being used recently, etc.
In one embodiment, a validator takes as a parameter a property. Using the value of the property, the validator determines if the property is valid. If the property is not valid, the validator indicates so by calling a method of the property. Some exemplary pseudo-code to perform this is as follows:
In one embodiment, a validator may be called by specifying a name (e.g., identifier) associated with the property and a validate method. For example, if a user data property having the name of “type” is contained in a userdata object, a validate method associated with the “type” property may be called as follows:
userdata[“type”].Validate( );
The construct userdata[“type”] returns an object that includes the “type” property. This “type” property includes a method (e.g., Validate) that can be called to validate the data within the property. It will be recognized by those skilled in the art that this embodiment of validating properties tightly couples the property to its validate method.
Additional validators may also be added to a particular property. In one implementation, this may be done by the following pseudo-code:
userdata[“type”].AddValidator(FunctionNameofValidator);
When the validate method of the property is called, the validators of the property may be called in the order in which they were added, for example. A property value is valid if each validator associated with the property indicates that the value is valid. If any validator associated with the property indicates that the value is not valid, the property is not valid. If there are no validators associated with a property, the property may be assumed to be valid by default.
In the password example above, a data input screen may request a password. It may be desirable to have immediate user feedback for certain of the criteria established for valid passwords. For example, it may be desirable to have an icon turn green when the user has entered enough letters to exceed the minimum length of a valid password. It may also be desirable to have another icon turn green when non-alphanumeric characters are entered. After the user tabs out of the password field, closes the window, hits an OK button, or takes another action outside the password field, it may be desirable to check whether the password has been used as one of the last twenty passwords, for example.
To have this occur, in one example, a password property object may be created. In one embodiment, three validators for the above three criteria may be associated with the password property. In a keystroke event of a user interface control associated with entering the password, the password property value may be updated to include data corresponding to the new keystroke. In addition, the validators associated with the length and non-alphanumeric criteria may be called to determine whether to light the icons. Because determining whether the password has been used in the last twenty times may be a more expensive operation, this validator may be called after the user takes action outside the password field.
In another embodiment, two validators may be associated with the password property. One of the validators may include actions for checking validation after each new keystroke. This validator may check the length and whether non-alphanumeric characters have been used in the password. This validator may also light up the icons associated with these criteria as appropriate.
The second of the validators may include expensive operations such as checking a database to determine whether the password has been used in the last twenty password changes for the user. This validator may be called after the user takes actions outside the password field.
In another embodiment, validators may be grouped together by passing the same identifier when adding another validator. For example, instead of putting all the code for validating inexpensive validators in one validator, the code may be placed in separate validators which are then both associated with a property using the same identifier. When a validate method is called with the identifier, all validators associated with the identifier may be called.
More, fewer, or different validators may be used without departing from the spirit or scope of aspects of the subject matter described herein.
Properties may also be validated at a screen or multi-screen level. For example, it may be difficult or impossible to validate some properties until other properties have been entered. For example, in a data input screen that receives an e-mail address, the input screen may request that the user enter the e-mail address in two separate fields to ensure that the e-mail address was not mistyped.
In the computer-ordering example above, information about computer options may be entered on multiple screens. A user may select a particular graphics card on one screen and a particular monitor on another screen. The graphics card may not be compatible with the monitor. This may be detected in a multi-screen level type validation, for example.
To address these types of issues, properties may be grouped in a collection (sometimes called a property bag). The property bag may have a validate method associated therewith. When the validate method of the property bag is called without an identifier of a validator, it may call the validate methods of each of the properties within the property bag in addition to any validators associated with the property bag itself. When the validate method of a property bag is called with a validator identifier, just the validator associated with the validator identifier may be called. In this way, validation across a collection of properties may be accomplished.
Furthermore, property bags may be collected in other collections (also sometimes called property bags or global property bags). For example, in the computer-ordering example above, the graphics card may be selected in one screen while the monitor may be selected in another. The screen in which the graphics card is selected may be associated with one property bag while the screen in which the monitor is selected may be associated with another property bag. A global property bag may include both the property bags.
The global property bag may be associated with a validate method. When the validate method of the global property bag is called without a validator name, it may call the validate methods of each of the property bags it contains in addition to any validators associated with the global property bag. When the validate methods of the property bags are called, they may call validate methods of properties within the property bag in addition to any validators associated with the property bags.
When the validate method of the global property bag is called with a validator identifier, it may call the validator method of the validator associated with the validator identifier. This validator may selectively determine to call validators of property bags or properties within the global property bag. In these ways, validation across a collection of property bags may be accomplished.
Global property bags may be collected into other property bags which may be collected into yet other property bags and so on. It will be recognized that this gives a very flexible way of validating properties, collections of properties, collection of collections of properties, and so forth.
Validators for properties or property bags may be named (e.g., identified) according to their function. For example, a property bag may have a validator with a “syntax” identifier. This validator may check the syntax for all properties within the property bag. As another example, a property bag may have a validator associated with “expensive” validation operations. For example, checking a database to determine whether a user name has already been used may be an expensive operation. To call this validator, a program may use the appropriate property bag and pass it the identifier (e.g., “expensive”) associated with expensive validation operations.
In one embodiment, a call to the validate method of a property without a parameter causes all validators associated with the property to be called. A call to a validate method of a property with an identifier parameter causes just the validator(s) associated with the identifier to be called. As discussed above, this works similarly for property bags.
In one embodiment, every property contains a nameless parent validation group. Identified property validators and/or validation groups may be added to this nameless group. When p.Validate( ) is called, all the named and nameless validators are called. Likewise, identified (named) validation groups can be added to other named validation groups to aid in grouping and organizing validation functions. One example of this is an email property which has a validator grouping named “expensive.” Within this grouping many different validation groupings may be added such as “AD,” “uniqueness,” and so forth. Then:
It will be recognized that this allows validation actions to be grouped via validators. Validators so grouped may be called without calling all the validators associated with a property or collection. Grouping may be done to perform inexpensive validation operations at one point and expensive operations at another point, for example. Calling a specific validator may be done, for example, by passing an identifier of a validator to the validate method. When the validate method is called without an identifier, it may in turn call all the validators associated with a property or property bag.
Below is some more pseudo-code that illustrates some examples of aspects of the subject matter described herein. Although the pseudo-code below indicates a guideline for implementing aspects of the subject matter described herein, it will be readily recognized that other mechanisms may also be used without departing from the spirit or scope of the subject matter described herein.
Below is some pseudo-code that represents an exemplary validation interface:
The IDictionaryValidation interface is defined like IValidation except that it ensures, using generics or compiler type checking, that all dictionary values are also validateable (i.e., implement IValidation). Implementers of the Validate( ) function of this interface call Validate( ) on every value.
Below is some pseudo-code that represents an exemplary IDictionaryValidation interface:
In one embodiment each of the entities 310-330 may comprise one or more user or kernel-mode processes or threads thereof.
The process 320 may comprise an application, operating system component, thread, or the like. In one embodiment, the process 310 may comprise a user interface component of an application that is in charge of receiving user input and ensuring that the input is valid. In another embodiment, the process 310 may comprise a process that receives a file of data to validate as described previously.
The validation module 312 includes a collection of validation components that may be used to validate data. The validation module 312 may include more, fewer, and/or other components than those shown in
The validator adder 315 operates to add validators for properties or collections. The add validator may associate a validator with a property or collection using an identifier associated with the validator and the property or collection as previously indicated.
The validator storage/retrieval 320 operates to store and retrieve validators from the memory 335. The validator storage/retrieval 320 may use any data store and format that is capable of storing and retrieving validators including a database, a dictionary object, a file, a data structure in memory, and so forth. Validators may be stored in the memory 335.
The validation engine 320 operates to validate properties or collections via the validators stored in the memory 335. In response to receiving a request to validate a property or collection, the validation engine 320 may execute one or more validators.
The error generator 325 is operable to indicate errors associated with validating a property or collection. The error generator 325 may store a list of errors associated with a validation as previously indicated. The error generator 325 is also further operable to provide errors in response to a request for the errors.
The memory 335 is any storage media capable of storing computer data and/or code. The memory 335 may be volatile or non-volatile. An example of a suitable media for the memory 335 is the computer-readable media discussed in conjunction with
The communications mechanism 340 allows the device 305 to communicate with other devices if needed to validate properties or collections. The communications mechanism 340 may be a network interface or adapter 170, modem 172, or any other mechanism for establishing communications as described in conjunction with
Turning to
At block 415, the property object is associated with a validator. For example, referring to
At block 420, a reference to the property object is placed in a collection. For example, referring to
At block 425, a reference to the collection is placed in a global collection. For example, referring to
At block 430, the property value is received. For example, referring to
At block 435, a property is validated via a validator. For example, referring to
At block 440, a group of properties values within a collection is validated. For example, referring to
At block 445, a group of properties values within a global collection is validated. For example, referring to
At block 450, the actions end.
Turning to
At block 510, an association between a property and validator is created. For example, referring to
At block 515, the association is stored. For example, referring to
At block 520, the property is placed within a collection of at least one other property. For example, referring to
At block 525, a request to validate the property and/or a collection is received. For example, referring to
At block 530, a validator is accessed. For example, referring to
At block 535, one or more validators associated with the property are executed if the request indicates validating a property. For example, referring to
At block 540, one or more validators associated with the collection are executed if the request indicates validating a collection. For example, referring to
At block 545, the action end.
As can be seen from the foregoing detailed description, aspects have been described related to a validation framework. While aspects of the subject matter described herein are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit aspects of the claimed subject matter to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of various aspects of the subject matter described herein.
