Patent Application
20060095403
In general, the present invention relates to generic way to filter (model) objects. Specifically, the present invention combines query filtering techniques with view filtering techniques to provide enhanced object querying and/or viewing.
User interfaces provide a way to display information using various types of “logical” or “display” structures that are suitable to an application such that a user can view and manipulate it in a meaningful way. Tree, table, list and other structures are commonly used to display lists of information. To assist a user who selects such a structure for displaying information, filtering mechanisms can be applied that are used to reduce the amount of information displayed to that which the user is interested in viewing. In general, there are two primary ways that information can be filtered:
1. View Filtering: Once a set of information has been retrieved via a query, the results are displayed in a structure (e.g., tree, table, list, etc.) where one or more view filters has been defined. Of the query results, those objects of data that meet the criteria of each view filter are displayed, while the others are not. This mechanism can be seen at work in current user interfaces including the ECLIPSE Integrated Development Environment (IDE) framework, where it is the primary means of data reduction for display to the user.
2. Query Filtering: In contrast to view filtering, where all information is retrieved upfront before being filtered, query filtering occurs at a lower level. Specifically, a set of one or more query filters is defined and passed into a query. The infrastructure that does the query does it in such a way that only information that meets the filter criteria are retrieved. Once those results come back to the widget for display, there is no need to filter at the widget level, since the data reduction occurred during the query itself. This mechanism can be seen at work in many applications, more notably database management tools, where queries are made explicitly to retrieve only the desired information. In ECLIPSE, the Remote System Explorer (RSE) also uses such a mechanism to reduce data when querying information from remote hosts.
The advantage of view filtering is that, at the structure level, it can be applied generically and dynamically to any set of data that is to be displayed. Regardless of the type of information and how such information is retrieved, each piece of data is displayed the same way; hence it is able to apply the same filtering criteria to anything that could be displayed. The advantage of query filtering is that when, in situations where queries can take a long time, such as those cases where enormous amounts of information are returned, especially with network latency involved, information is reduced at its source, less time and bandwidth is wasted in bringing irrelevant results to the user interface.
It's common to provide filtering in a static way, such that filters are predefined or explicitly defined prior to displaying information in a structure. More advanced structures take this further to provide more dynamic filtering usage. For example, there are dialogs that provide an entry field so that a user may input a pattern representing the filter criteria/string to apply on a view. An example of this is the ECLIPSE “Open Type” dialog 10 shown in
Alternatively, when strictly a query filter is used to provide such a structure, there are different problems. Since no information exists up-front, each time a user alters the filter string, a new query needs to be made to retrieve the view results. Large queries can be expensive and since these would happen as frequently as the user types, the expense is compounded.
In view of the foregoing, there exists a need for a compromise to be made that inherits the benefits and solves the problems of each of these mechanisms. Specifically, a need exists for a system to provide both view filters and query filters in concert. Each filter references the same filter string, providing its own data reduction in its own way. To this extent, a need exists for a method, system and program product for filtering model objects.
In general, the present invention combines both query filter and view filter concepts to provide an improved method, system and program product for filtering model objects. Specifically, rather than retrieving an entire set of information up-front, a query filter will be applied so that only necessary information needed for the current filter string/criteria is retrieved. Once that set of data is retrieved, a view filter based on the filter string is applied. If the view filter initially matches all the information retrieved, no further reduction of information occurs at that point. However, if a user later alters the filter string such that it is more specialized (and hence a subset or within of the original filter string), then a new view filter will be applied on the current set of data to reduce it accordingly (since all information necessary for that filter has already been retrieved). If, on the other hand, a user alters the filter string such that it is more general and not within the initial filter string from which the initial query was made, a new query filter would be created to match the “delta” of the new filter string compared to the initial filter string—after the results are retrieved for the delta query, both the initial query results and the new query results would be compared against the new view filter so that only matching objects from those sets are displayed. By combining the two types of filters in this way, any upfront query expense is reduced via the delta query filters, while the view filter provides the means of reducing any overlap of data that exists as a result of cached query results.
A first aspect of the present invention provides a computer-implemented method for filtering objects, comprising: receiving input for an object and a filter string; determining whether the filter string was used in a previous query, and generating a query filter based on the filter string if the filter string was not used in a previous query; generating a query for the object to be performed while applying the query filter, and receiving results of the query; generating a view filter based on the filter string, and filtering the results using the view filter; and generating a view of the results after the results have been filtered using the view filter.
A second aspect of the present invention provides a computerized system for filtering objects, comprising: a system for receiving input for an object and a filter string; a system for determining whether the filter string was used in a previous query; a system for generating a query filter based on the filter string if the filter string was not used in a previous query; a system for generating a query for the object to be performed while applying the query filter, and for receiving results of the query; a system for generating a view filter based on the filter string; a system for filtering the results using the view filter; and a system for generating a view of the results after the results have been filtered using the view filter.
A third aspect of the present invention provides a program product stored on a recordable medium for filtering objects, which when executed, comprises: program code for receiving input for an object and a filter string; program code for determining whether the filter string was used in a previous query; program code for generating a query filter based on the filter string if the filter string was not used in a previous query; program code for generating a query for the object to be performed while applying the query filter, and for receiving results of the query; program code for generating a view filter based on the filter string; program code for filtering the results using the view filter; and program code for generating a view of the results after the results have been filtered using the view filter.
A fourth aspect of the present invention provides computer software embodied in a propagated signal for filtering objects, the computer software comprising instructions to cause a computer system to perform the following functions: receive input for an object and a filter string; determine whether the filter string was used in a previous query, and generating a query filter based on the filter string if the filter string was not used in a previous query; generate a query for the object to be performed while applying the query filter, and receive results of the query; generate a view filter based on the filter string, and filtering the results using the view filter; and generate a view of the results after the results have been filtered using the view filter.
A fifth aspect of the present invention provides a method for deploying an application for filtering objects comprising: providing a computer infrastructure being operable to: receive input for an object and a filter string; determine whether the filter string was used in a previous query, and generating a query filter based on the filter string if the filter string was not used in a previous query; generate a query for the object to be performed while applying the query filter, and receive results of the query; generate a view filter based on the filter string, and filtering the results using the view filter; and generate a view of the results after the results have been filtered using the view filter.
Therefore, the present invention provides method, system and program product for filtering objects.
These and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings in which:
The drawings are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. The drawings are intended to depict only typical embodiments of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numbering represents like elements.
As indicated above, the present invention combines both query filter and view filter concepts to provide an improved method, system and program product for filtering model objects. Specifically, rather than retrieving an entire set of information up-front, a query filter will be applied so that only necessary information needed for the current filter string/criteria is retrieved. Once that set of data is retrieved, a view filter based on the filter string is applied. If the view filter initially matches all the information retrieved, no further reduction of information occurs at that point. However, if a user later alters the filter string such that it is more specialized (and hence a subset or within of the original filter string), then a new view filter will be applied on the current set of data to reduce it accordingly (since all information necessary for that filter has already been retrieved). If, on the other hand, a user alters the filter string such that it is more general and not within the initial filter string from which the initial query was made, a new query filter would be created to match the “delta” of the new filter string compared to the initial filter string—after the results are retrieved for the delta query, both the initial query results and the new query results would be compared against the new view filter so that only matching objects from those sets are displayed. By combining the two types of filters in this way, any upfront query expense is reduced via the delta query filters, while the view filter provides the means of reducing any overlap of data that exists as a result of cached query results.
It should be understood in advance that as used herein, the term “model object” is intended to refer to any object that represents a piece of data. Referring now to
In any event, as shown, client 22 includes processing unit 26, memory 28, bus 30, input/output (I/O) interfaces 32, external devices/resources 34 and storage unit 36. Processing unit 26 may comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g., on a client and server. Memory 28 may comprise any known type of data storage and/or transmission media, including magnetic media, optical media, random access memory (RAM), read-only memory (ROM), a data cache, a data object, etc. Moreover, similar to processing unit 26, memory 28 may reside at a single physical location, comprising one or more types of data storage, or be distributed across a plurality of physical systems in various forms.
I/O interfaces 32 may comprise any system for exchanging information to/from an external source. External devices/resources 34 may comprise any known type of external device, including speakers, a CRT, LED screen, hand-held device, keyboard, mouse, voice recognition system, speech output system, printer, monitor/display, facsimile, pager, etc. Bus 30 provides a communication link between each of the components in client 22 and likewise may comprise any known type of transmission link, including electrical, optical, wireless, etc.
Storage unit 36 can be any system (e.g., a database, etc.) capable of providing storage for information under the present invention. Such information could include, for example, view adapters 60, query adapters 62, property adapters 64, etc. As such, storage unit 36 could include one or more storage devices, such as a magnetic disk drive or an optical disk drive. In another embodiment, storage unit 36 includes data distributed across, for example, a local area network (LAN), wide area network (WAN) or a storage area network (SAN) (not shown). Although not shown, additional components, such as cache memory, communication systems, system software, etc., may be incorporated into client 22. Moreover, it should be understood that server 24 will include computerized components similar to client 22. Such components have not been depicted for illustrative purposes only.
Shown in memory 28 of client 22 as a program product is object filter system 38, which includes input system 40, comparison system 42, query filter system 44, query system 46, population system 48, view filter system 50 and view refresh system 52. It should be appreciated that object filter system 38 could be incorporated within (e.g., as a plug-in) or work in conjunction with any other program such as an Integrated Development Environment (e.g., ECLIPSE). The precise workings of object filter system 38 and its sub-systems will be further described in conjunction with
Each view adapter 60 provides an interface associated with any given model object type that declares methods for getting information about an object to display in a structure. Each view adapter 60 typically includes methods to return the display text and icon associated with a given object. For example, a view adapter 60 for a Java class would define methods for returning the name of a class and the icon used in displaying a class in a viewer. The viewer would call both these methods to display an object in a list, while a view filter would call the getText(Object modelObject) method to determine whether its filter criteria can be met. Each query adapter 62 provides an interface associated with any given model object type that declares methods for querying the object contents of a particular data object. This interface, query(Object modelObject, String filterString), is the generic means by which a widget can get the model data to display in a view. The query adapter 62 is to be associated with any given input to a view (i.e., the container of any results) displayed in view 58. In the case where all classes are to be retrieved, this object may be the root of the Java Model, itself. The associated query adapter 62 would define its own query( ) method such that it would use the appropriate JDT model methods to return a set of Java objects matching the specified filter string. A simpler example is the case where a folder is the input to the view 58. In that case, the query adapter 62 for a folder would implement the query( ) method so that only the child files and folders that match a given filter string are returned.
Referring now to
Once this information is provided, it will be received by input system 40 (
As depicted in
Referring now to
Regardless, the exemplary new filter string 57 shown in
Turning to
The results of the query will be further filtered by a new view filter that is generated by view filter system 50 (
It should be understood that although not described in the illustrative example discussed above, it is possible for object input 54 (
As indicated above, property adapters 64 could be utilized in addition to view adapters 60 and query adapters 62 to enhance the filtering process. Under the present invention, each property adapter 64 provides an interface associated with any given model object type that declares methods for getting property information about a data object. A property adapter 64 typically includes methods to return the set of property descriptors associated with the object type along with methods to return the particular value for one such property on a specific data model object. For example, the following methods would likely be defined:
IPropertyDescriptor [ ] getPropertyDescriptors (Object modelObject)
String getPropertyValue (IPropertyDescriptor descriptor, Object modelObject)
In the ECLIPSE IDE, property adapters (or IPropertySource implementations) are used by a property sheet viewer to display the list of properties for a given object along side its values. For example, referring to
Modifying any of the fields 120 would affect the view filtering and optionally the query filtering. For the view filtering to account for additional properties, the implementation of a view filter 60 would be altered as follows: (1) a view filter having of a set of filter strings (i.e. an array of strings) that map to the properties would be generated; (2) the view filter would be passed a property adapter for use in this more sophisticated way to do filtering; and (3) the view filter would compare each of the filter strings against each of the property values to determine whether or not a specific model object can be shown.
For the query filtering to account for additional properties, the implementation of the query adapter 64 would be altered as follows: (1) the query( ) API would need to allow specification of filters for properties. For example, the API could be changed to: query(String[ ] property, String[ ] propertyValueFilters).
Referring now to
With respect to the filter string received in step S2, in step S9, it will be determined whether the object input received in step S1 was null. If so, the process will terminate in step S10. However, if the object input was not null, it will be determined in step S11 whether the QRSFL contains the filter string. If not, the process will flow back through steps S4-S8 as discussed above. However, if the QRSFL contained the filter string, a new query need not be conducted. Rather, the view filter would be updated and applied in step S7 and the view refreshed in step S8 as discussed above.
It should be understood that although a particular sequence in which events occurred was described above, some of the events could have occurred in a different sequence. For example, view filter system 50 (
It should also be appreciated that the present invention could be offered as a business method on a subscription or fee basis. For example, object filter system 38 could be created, supported, maintained and/or deployed by a service provider that offers the functions described herein for customers. That is, a service provider could offer to filter model objects for customers.
Still yet, it should be understood that the present invention could be realized in hardware, software, a propagated signal, or any combination thereof. Any kind of computer/server system(s)—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when loaded and executed, carries out the respective methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention, could be utilized. The present invention can also be embedded in a computer program product or a propagated signal, which comprises all the respective features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program, propagated signal, software program, program, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
The foregoing description of the preferred embodiments of this invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of this invention as defined by the accompanying claims.
