Patent Publication Number: US-8972900-B2

Title: Client-side generation and filtering of hierarchy information

Description:
TECHNICAL FIELD 
     This document relates to client-side generation and filtering of hierarchy information. 
     BACKGROUND 
     Information can be organized as a hierarchy in many different situations. For example, products from a manufacturer and/or components of such products can be structured as a tree where each node except a root node has a parent node. 
     When tree information is to be displayed at a client device, an approach called “lazy load” is sometimes used. For example, a lazy load can mean that only the part(s) of the tree that are currently to be visible are actually retrieved from the server. That is, for any parent node that is currently not expanded, its child nodes are not retrieved. If and when the parent node is expanded, the lazy load retrieves the child node(s). However, lazy load may require that the server side is aware of the hierarchical nature of the information, and further filtering of the retrieved nodes may not be provided. 
     SUMMARY 
     The invention relates to client-side generation and filtering of hierarchy information. 
     In a first aspect, a computer-implemented method for displaying a filterable hierarchy includes: receiving, in an application, a user input that requests at least part of a hierarchy to be displayed; generating a request based on the user input, and forwarding the request to a server for performing a query on non-hierarchical information in a database; receiving, in the application, a response by the server to the request; identifying, in the response, at least one selectable node in the hierarchy and at least one non-selectable visible node in the hierarchy; and presenting, using the application, a view in which the selectable node and the non-selectable visible node are structured according to the hierarchy. 
     In a second aspect, a computer program product is tangibly embodied in a computer-readable storage medium and includes instructions that when executed by a processor perform a method for displaying a filterable hierarchy. The method includes: receiving, in an application, a user input that requests at least part of a hierarchy to be displayed; generating a request based on the user input, and forwarding the request to a server for performing a query on non-hierarchical information in a database; receiving, in the application, a response by the server to the request; identifying, in the response, at least one selectable node in the hierarchy and at least one non-selectable visible node in the hierarchy; and presenting, using the application, a view in which the selectable node and the non-selectable visible node are structured according to the hierarchy. 
     In a third aspect, a system includes: one or more processors; and a computer program product tangibly embodied in a computer-readable storage medium and comprising instructions that when executed by the one or more processors perform a method for displaying a filterable hierarchy. The method includes: receiving, in an application, a user input that requests at least part of a hierarchy to be displayed; generating a request based on the user input, and forwarding the request to a server for performing a query on non-hierarchical information in a database; receiving, in the application, a response by the server to the request; identifying, in the response, at least one selectable node in the hierarchy and at least one non-selectable visible node in the hierarchy; and presenting, using the application, a view in which the selectable node and the non-selectable visible node are structured according to the hierarchy. 
     Implementations can include any or all of the following features. The non-hierarchical information in the database includes a plurality of entries each having a multivalued field, and the multivalued fields are used in the application for structuring the selectable node and the non-selectable visible node according to the hierarchy. The request calls for at least first and second records to be generated from the non-hierarchical information, the first record corresponds to nodes of the hierarchy filtered for a user, including the selectable node, and the second record corresponds to parent nodes to the nodes in the first record. The view presents the hierarchy opened to a number of levels based on the user input. The user input corresponds to a user expanding a node in the hierarchy. Another view of the hierarchy was previously presented, the other view filtered for a user, and the user input is generated by the user and corresponds to initiating another filtering of the hierarchy. An administrator specifies that the selectable node is selectable by assigning a user identifier to the selectable node, and a node having no assigned user identifier is selectable by all users who have access to the hierarchy. The non-hierarchical information in the database includes a plurality of entries each having a multivalued field, and the multivalued fields are used in structuring the selectable node and the non-selectable visible node according to the hierarchy. 
     Implementations can provide any or all of the following advantages. A filtered tree can be displayed up to an arbitrary level while obtaining: a minimum amount of network traffic; a minimum use of client resources (e.g., processor or memory); the tree structure is maintained; the filter criteria can be changed by the user or defined according to a user role; any previous node selection in the tree is displayed, as are its parents and any node along the path to the selected node that meets the filter criteria; the user can apply further filtering on top of the filter that was done when the current tree was displayed; and/or compressed paths can be used when there is a direct path to the next filtered child node. 
     The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  shows an example cloud architecture that can provide filtering of a hierarchy. 
         FIGS. 2A-C  show examples of selectable nodes and non-selectable visible nodes. 
         FIG. 3  shows an example view for specifying selectable nodes and non-selectable visible nodes. 
         FIG. 4  shows an example of a request sent from a client side to a server. 
         FIGS. 5A-B  show an example of a response sent from the server to the client side. 
         FIG. 6  is a block diagram of a computing system that can be used in connection with computer-implemented methods described in this document. 
     
    
    
     Like reference symbols in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
     This description relates to client-side generation and filtering of hierarchy information. For example, data can be stored in a database in a non-hierarchical fashion, for example as individual rows in a database table. A client application that should display a tree structure can then generate a query for a database server, and from the delivered results the client application can assemble the requested information according to the tree structure. That is, this can eliminate a need to introduce client-specific features in the server, for example such that the server logic need not be aware that the stored information is to be structured in tree form. 
       FIG. 1  shows an example cloud architecture  100  that can provide filtering of a hierarchy. Here, the cloud architecture is schematically organized into a client layer  102 . an application layer  104 , a cloud platform and infrastructure layer  106  and a server and database layer  108 . One or more other layers can also or alternatively be used. 
     The client layer  102  and the application layer  104  can be considered the client-side aspects of the cloud architecture  100 . The client layer  102  can include any form of client device or module including, but not limited to, a browser or other program executed on a personal computer or on a smartphone. The application layer  104  can include one or more applications created for interaction with the client layer  102 . For example, the application layer can include an application that it makes available to each of multiple users according to the cloud computing paradigm that is sometimes used to provide services over a network. The cloud architecture  100  can use any type of computer network, for example a private network or a public network. 
     The cloud platform and infrastructure layer  106  can facilitate the operations of one or more applications in the application layer  104 , such as to provide services over the internet. The cloud platform and infrastructure layer can expose services to the application layer that the applications can use to process or retrieve information. For example, such services can relate both to the substantive operations of the application(s) and to the communications (e.g., by a secure login) to and from the users. 
     The server layer  108  in this example maintains at least one data base  110 . In some implementations, the database has stored therein non-hierarchical information, for example in form of basic relational-database tables. The server layer executes server logic that is responsible for storing information in the database  110 , receiving requests from one or more applications, querying the database, and providing responses to the requests. For example, the server logic can implement a database management system that is configured for querying the database, such as by structured query language (SQL). 
     An example of operations in the cloud architecture  100  will now be described. The example involves a tree structure that an application in the application layer  104  displays to a user in the client layer  102 , for example in a form filtered to that user. At  112 , the application layer  104  receives an input from the client layer  102 . For example, the user chooses to expand a currently unexpanded node. In this example, expanding a node requires that more information be obtained from the database  110 , such as in the following way. 
     At  114 , the application formulates an XML (extensible markup language) statement that is based on the input. For example, the application can create the XML statement so that it corresponds to a suitable database query. Such database query can in turn reflect the current situation that a currently unexpanded node should be expanded, and one or more of its child nodes should be displayed. At  116 , the application sends the request for receipt in the server layer  108 . 
     At  118 , a server in the server layer  108  receives the XML statement as part of the request. At  120 , the server converts the XML statement to a database query, for example an SQL query. That is, the SQL query then reflects what information should be retrieved so that the currently unexpanded node can be displayed in expanded form. 
     At  122 , the server runs the query (e.g., SQL) on the database  110 . An SQL query can be formulated to include one or more select, from, where, group by, having or order by statements, to name just a few examples. In some implementations the query involves a self-join and group by statements, as will be described below. In any event, the information on which the query is executed is non-hierarchical; that is, the server logic is not aware of any hierarchical structure among the various data portions. 
     At  124 , the search result is converted to XML, for example by essentially the reverse of the conversion performed at  120 . A response to the request is sent at  126 , the response including the XML statement generated for the requesting application. 
     At  128 , the response is received in the application layer  108 . The application uses the response at  130  to determine at least one selectable node and a non-selectable visible node in relation to the particular user input (received at  112 ). Examples of this will be described below. 
     At  132 , the application generates an output to the client layer  102 . In some implementations, the application can forward code or other information for receipt by a browser, wherein the browser uses the code or other information to display a view of the hierarchy. In the current example, the output is used to display the node in an expanded state, and the displayed view accordingly now also includes one or more child nodes that were not displayed before the expansion. For example, a current node and a condition for visibility/selectability of nodes are input from the client side, and the response provides the list of children that either meet the filter condition(s), or that have direct children—or indirect children at an arbitrary level—that meet the filter condition(s). The expansion of the hierarchy is accomplished with a single roundtrip to the server, based on a query formulated by the client application. This can tend to minimize network traffic while utilizing lazy load to support large data structures that cannot entirely be kept at the client side. 
     A similar processing can be performed whenever a hierarchy is to be displayed or refreshed. For example, a hierarchy can be displayed such that the tree is opened to N (i.e., an arbitrary number) of levels. The number of levels to be opened can be set based on one or more factors, for example a user preference or a user role specification. As another example, an additional query can be run on top of the query that is currently the basis for the tree. 
       FIGS. 2A-C  show examples of selectable nodes and non-selectable visible nodes. Particularly,  FIG. 2A  shows a “select nodes” view  200 A for an administrator;  FIG. 2B  shows a select nodes view  200 B for a first user (here referred to as “Engineer1”); and  FIG. 2C  shows a select nodes view  200 C for a second user (here referred to as “Engineer2”). These views all relate to the same underlying hierarchy, which in this example is a tree of car makes, models and components. For clarity, the hierarchy that is the basis for the views  200 A-C shows only a few car manufacturers, and only a limited set of car models from those car makers. Moreover, while a great number of components are part of each of these cars, only a few example components are shown. In some implementations, the hierarchy can have significantly more levels than shown here, and/or can have many more components at each level. 
     In the administrator&#39;s view  200 A the hierarchy is shown in its entirety. The hierarchy includes three car makes Toyota, Mercedes-Benz and Lotus, represented by nodes  202 A-C, respectively. The Toyota car make here has three models listed: Lexus, Daihatsu and Toyota Celica, represented by nodes  204 A-C, respectively. 
     Each of the car model nodes  204 A-C can have zero or more child nodes. Here, the Lexus model has a child represented by node  204 A which is called “Lexus 2054”; the “Applause” child of the Daihatsu model has node  206 B; and the “SS-II” child of the Toyota Selica model has node  206 C. Moreover, each of the nodes  206 A-C may have zero or mode child nodes. Here, only the node  206 C is currently expanded, and a node  208  called “2ZZ-GE Engine” is therefore displayed. 
     For each node in the hierarchy, the administrator can decide whether the node should be selectable by all users with access to the hierarchy, or only selectable to certain users. Such restriction can be specified in any of multiple ways, including but not limited to, by user identity, user organization, or user role, to name just a few examples. In this example, the administrator specifies the node selectability to be as follows: 
     
       
         
           
               
               
               
               
             
               
                   
                   
               
               
                   
                 Node number 
                 Node name 
                 Is selectable to 
               
               
                   
                   
               
             
            
               
                   
                 202A 
                 Toyota 
                 All users with access 
               
               
                   
                 204A 
                 Lexus 
                 Engineer2 
               
               
                   
                 206A 
                 Lexus 2054 
                 Engineer2 
               
               
                   
                 204B 
                 Daihatsu 
                 All users with access 
               
               
                   
                 206B 
                 Applause 
                 All users with access 
               
               
                   
                 204C 
                 Toyota Celica 
                 Engineer1 
               
               
                   
                 206C 
                 SS-II 
                 Engineer1 
               
               
                   
                 208 
                 2ZZ-GE Engine 
                 All users with access 
               
               
                   
                 202B 
                 Mercedes-Benz 
                 All users with access 
               
               
                   
                 202C 
                 Lotus 
                 All users with access 
               
               
                   
                   
               
            
           
         
       
     
     In other words, the selectability is here restricted in at least two specific ways. First, the nodes  204 A and  206 A, which correspond to an entire branch under the Toyota node  202 A, are selectable only to Engineer1. That is, these nodes are not selectable to any other user according to this specification. Second, the leaf node  208  is selectable to all users with access to the hierarchy, although its nearest parent nodes—the SS-II node  206 C and the Toyota Celica node  204 C—are only selectable to Engineer1. That is, this is an example where the beginning of a branch is selectable only to a specific user, while a deeper node in the same branch is selectable to a larger group of users. The above two restrictions will affect how the hierarchy is displayed to users, particularly to Engineer1 and Engineer2 in this example. 
       FIG. 2B  shows the select nodes view  200 B for Engineer1. For example, a filtering of a large hierarchy is performed based on who the user is (or what the current work task is, etc.) and this filtered result forms the basis for generating the view  200 B. In some situations, one or more nodes that do not meet the filtering criterion may also be displayed, for example because they are the parent node of a selectable node. 
     Here, the view  200 B includes the nodes  202 A,  204 B,  206 B,  204 C,  206 C,  208 ,  202 B and  202 C. For clarity, all the displayed nodes are here shown as expanded, although this can be modified by the user or depending on the particular situation. The shown nodes are all selectable to Engineer1 according to the administrator specification and they are therefore displayed with normal (i.e., not grayed-out) appearance. However, the nodes  204 A and  206 A ( FIG. 2A ), which were restricted as only selectable by another user, are not displayed with the hierarchy. This is because those nodes are an entire branch under the Toyota parent node  202 A. For example, it can be assumed that Engineer1 does not have a strong need to see either of the nodes  204 A and  206 A in such situation. However, the remainder of the hierarchy structure is preserved for Engineer1 in this view, which can help this user understand the relationships between the different nodes that are selectable. The user (here Engineer1) can select one or more of the selectable nodes and then click an OK button  210 . The user can make this selection for any of multiple purposes including, but not limited to, the ordering of a product, component or part, or to document work that has been performed regarding such item. 
     Additional filtering can be performed. In some implementations, the user can run a new filtering on top of the one that was the basis for the current version of the view  202 B. For example, Engineer1 may initially have received a first set of filtered nodes, and may later decide to run additional filtering that is more, or less, encompassing than the first set of nodes, or that seeks an entirely different set of nodes. 
       FIG. 2C , in turn, shows the select nodes view  200 C for Engineer2. Here, the view  200 C includes the nodes  202 A,  204 A,  206 A,  204 B,  206 B,  204 C,  206 C,  208 ,  202 B and  202 C. One difference compared to Engineer1&#39;s view is that the nodes  204 A and  206 A are here displayed. This is a result of the administrator specification described earlier. Moreover, these nodes were specified as selectable to Engineer2 and therefore have normal appearance. 
     However, not all of the displayed nodes are selectable to Engineer2. Particularly, the nodes  204 C and  206 C are here grayed-out as an indication that they are not selectable by this user. This is also a result of the administrator specification described earlier. However, the leaf node  208  has been specified as selectable by all users with access (and therefore by Engineer2), and this node therefore has a normal appearance like other selectable nodes. 
     That is, the view  202 C in this example has preserved the hierarchy structure when a deeper node (here the leaf node  208 ) is currently selectable although one or more of its parent nodes are not. Preserving the hierarchy structure can help the user understand the context of a selectable node and avoid confusion with other nodes that may have similar names. Also, the preserved hierarchy structure can allow the user to collapse or expand a tree branch at will, which can be useful, for example, when only a few leaf nodes are selectable out of an otherwise complex branch of nodes. 
     The entire hierarchy structure is not necessarily preserved in the displayed view, however. Take for example the view  200 B ( FIG. 2B ) which is displayed to Engineer1. This view omits the entire branch of nodes  204 A and  206 A (shown in  FIG. 2A ), for example because it is assumed that the current user (here Engineer1) does not have a great need to see branches in which that user cannot select any node, and showing such non-selectable nodes could perhaps make the view more difficult to use. That is, in each displayed view the hierarchy structure can be preserved in some parts and omitted in other parts. Moreover, in the preserved parts the nodes can be marked differently (e.g., greyed-out) to indicate the difference between a selectable node and a non-selectable visible node. 
       FIG. 3  shows an example view  300  for specifying selectable nodes and non-selectable visible nodes. In some implementations, an administrator can use the view  300  to specify selectability and/or non-selectability of one or more nodes, for example as described above. 
     The view  300  includes a nodes area  302 , which can specify one or more characteristics of each node. Here, the node&#39;s name, full name and ancestors are listed in respective columns. Other information can additionally or instead be shown, including, but not limited to, a node identifier, node type, or relevant statistics. In some implementations, the nodes area  302  can be displayed in any of multiple modes, currently a “Hierarchy View,” which shows the hierarchy structure of the tree by organizing the nodes in a particular order and by using horizontal indents for child nodes. 
     In this example, the nodes shown in the nodes area  302  generally correspond to those described above. Currently, a “Lexus 2054” node has focus in the nodes area  302 . 
     The view  300  includes a node editing area  304 , which is used to enter, edit and/or remove information about the node in focus. Here, the node editing area includes a name field, a full name field and a parent ID field. For example, the parent ID field can be used to reassign the node in focus from its current parent node to another parent node. The full name field can then be updated accordingly to reflect the change. 
     The view  300  includes an ancestors area  306  which indicates the node in focus and which, if any, of the other nodes that are parents to that node either directly or indirectly. This corresponds to the information in the ancestors column of the nodes area  302 . Here, the ancestors area  306  shows that “Toyota” and “Lexus” are the ancestors. 
     The view  300  includes an allowed user area  308  where the selectability or non-selectability of one or more nodes can be specified. In some implementations, the administrator leaves the allowed user area blank to make the node selectable to all users with access to the hierarchy. That is, general selectability can be the default setting for each node. In contrast, the administrator can enter one or more user names, IDs, groups and/or roles to restrict the selectability accordingly. As described in examples above, a node that is non-selectable to a current user is either displayed to that user (e.g., the nodes  204 C and  206 C are displayed in  FIG. 2C ), or not displayed to that user (e.g., the nodes  204 A and  206 A are not displayed in  FIG. 2B ). 
       FIG. 4  shows an example of a request  400  sent from a client side to a server. In some implementations, the request  400  is sent from the application layer  104  ( FIG. 1 ) to the server layer  108 . The request can be formulated using any suitable code, script or other language. In some implementations, the client side formulates the request using an intermediary language which is later converted to a query language (e.g., SQL) for execution on a database. Here, the request  400  is formulated in XML. For simplicity, the following description of the XML statements will occasionally describe the execution of the query, or the results thereof, it being implied that the request language has then first been translated into a proper query language. 
     The request  400  in this example is one that is sent when a user expands the Toyota node  202 A ( FIGS. 2A-C ). Particularly, in the nodes area  302  ( FIG. 3 ), the ancestors column contains the identifier for the node  202 A. That is, because the node  202 A is the root node in this example, only its own ID—and no ancestor IDs—are listed in the ancestors column. In contrast, a child node such as the Lexus node ( 204 A in  FIG. 2A ) has first its own ID listed in the ancestor column, and thereafter the ID of its parent(s), in this example the ID of the Toyota node. 
     The request  400  includes a condition  402 . In some implementations, a condition is used in the determination of whether a node should be displayed as a selectable node, as a non-selectable visible node, or not be displayed at all. Here, the condition  400  has the following structure:
         condition  402 A
           AND   
           condition  402 B
           AND   
           condition  402 C       

     wherein the conditions are associated by logical AND operators. Moreover, the condition  402 B here contains a logical OR operator, as will be discussed later. 
     The condition  402 A relates to whether a node is obtained through filtering or because the node is an ancestor of a node that is obtained through the filtering. Particularly, the request  400  generates two records, or documents, sometimes called “copies” of the database table. They are here referred to as $doc1 and $doc2, respectively. The $doc1 contains nodes that match the filtering criteria; that is, the nodes that an administrator has specified should be selectable by (at least) this particular user. The $doc2, in contrast, contains the nodes that are ancestors of the nodes in $doc1. 
     In this example, the equal sign (=) in the condition  402 A describes a one-to-many relation. That is, of the terms in the condition  402 A, “ID” is here a single value while “ancestors” is a multivalued (or “repeating”) field. In some implementations, one-to-many relations can instead be described using an “in” expression. 
     The condition  402 B relates to the selectability of the node for a given user. Here, the condition  402 B has a first section that determines whether the string length of allowed users is zero. For example, when the default setting is that specifying no particular allowed user leads to the node being generally selectable, then a zero string length corresponds to that situation. The condition  402 B also has a second portion associated to the first portion by a logical OR operator. The second portion determines whether the ID of the current user (here called “MemberID”) is specified in the allowed-user field. In either of these situations, the particular node should be selectable by the current user and the node can therefore be displayed with normal appearance. 
     In some implementations, the condition  402 B is completely configurable by an administrator. The condition  402 B can rely on data, or user permissions, or both, to name just a few examples. 
     The condition  402 C, finally, relates to the current node being the child of the particular node being expanded (in this example the Toyota node). 
     The request  400  also includes a group by portion  404  that relates to compressing the hierarchy to what is currently of interest. That is, the group by portion  404  can ensure that any specific node occurs in the $doc2 only once. Otherwise, a node could appear twice in the $doc2: first because the node itself is a filtered node, and then because it is a parent node to another filtered node. 
     The request  400  also includes an aggregation portion  406 . For example, if the same node appears both in $doc1 and in $doc2, then the aggregation informs the system that the node in $doc2 is not a direct child node of an expanded parent node, but rather a filtered node (i.e., a node that met the filtering criteria). 
       FIGS. 5A-B  show an example of a response  500  sent from the server to the client side. The response  500  is here written in XML code. In some implementations an SQL query is performed in the database  110  ( FIG. 1 ) and the result is converted to a suitable form—e.g., XML—before sending the response to the client side. 
     The response  500  includes a group by portion  502 . In this example, the group by portion relates to the group by portion  404  ( FIG. 4 ). 
     The response  500  includes IDs of nodes. For example, ID  504  corresponds to the Daihatsu node  204  B ( FIGS. 2A-C ), and ID  506  corresponds to its parent node, the Toyota node  202 A ( FIGS. 2A-C ). For example, these nodes occur in the Full Name field of the node editing area  304  ( FIG. 3 ) when the Daihatsu node has focus in the nodes area  302 . The response also includes an ID  508  that is also the ID of the Daihatsu node (i.e., the same as ID  504 ). For example, this node occurs in the Name field of the node editing area  304  ( FIG. 3 ) when the Daihatsu node has focus in the nodes area  302 . The response also includes the name “Daihatsu” (at  510 ) and the two names “Toyota” and “Daihatsu” (at  512 ). 
     At  514 , the response  500  includes corresponding information about the Toyota Celica node, which has the same parent node. 
     A value  514  for the Daihatsu node is “0” in this example, while a corresponding value  516  for the Toyota Celica node is “1”. The “0” value indicates that the Daihatsu node is present because it meets the filtering criteria for the current user; that is, this node is selectable. The “1” value, on the other hand, indicates that the Toyota Celica node is present—not for meeting the filtering criteria, but rather—because it has a child node (direct or indirect) that meets the criteria. For example, this corresponds to the situation in  FIG. 2C , where the Toyota Celica node  204 C is present because it has the deeper node  208  that is selectable to this user. 
       FIG. 6  is a schematic diagram of a generic computer system  600 . The system  600  can be used for the operations described in association with any of the computer-implement methods described previously, according to one implementation. The system  600  includes a processor  610 , a memory  620 , a storage device  630 , and an input/output device  640 . Each of the components  610 ,  620 ,  630 , and  640  are interconnected using a system bus  650 . The processor  610  is capable of processing instructions for execution within the system  600 . In one implementation, the processor  610  is a single-threaded processor. In another implementation, the processor  610  is a multi-threaded processor. The processor  610  is capable of processing instructions stored in the memory  620  or on the storage device  630  to display graphical information for a user interface on the input/output device  640 . 
     The memory  620  stores information within the system  600 . In some implementations, the memory  620  is a computer-readable medium. The memory  620  is a volatile memory unit in some implementations and is a non-volatile memory unit in other implementations. 
     The storage device  630  is capable of providing mass storage for the system  600 . In one implementation, the storage device  630  is a computer-readable medium. In various different implementations, the storage device  630  may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. 
     The input/output device  640  provides input/output operations for the system  600 . In one implementation, the input/output device  640  includes a keyboard and/or pointing device. In another implementation, the input/output device  640  includes a display unit for displaying graphical user interfaces. 
     The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. 
     Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits). 
     To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer. 
     The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet. 
     The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. 
     A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. Accordingly, other implementations are within the scope of the following claims.