Abstract:
A method is provided, the method including (a) storing a set of drag-and-drop properties associated with an object in a properties file, the properties file being stored on a tangible computer readable medium, and (b) implementing a program in software. The program includes an instantiation of the object and a method for handling drag-and-drop features associated with the instantiated object with reference to the set of drag-and-drop properties stored in the properties file. Software and data structure methods are provided as well.

Description:
BACKGROUND 
     In a typical data storage system management application, various physical and logical aspects of the data storage system may be displayed in a hierarchical manner on a graphical user interface (GUI). In order to re-arrange logical aspects of the data storage system, a typical implementation requires properties fields of the various elements to be textually modified. For example, in order to add a logical unit of storage (LUN) to a storage group, a storage group properties box is opened, and a button is clicked to indicate that a new LUN should be added to that storage group. This would bring up a dialog box asking the user to select a particular LUN from a list of known LUNs to add to that storage group. 
     SUMMARY 
     Unfortunately, these conventional data storage system management applications are deficient. In particular, they require a cumbersome procedure to rearrange elements. In contrast, embodiments of the present invention improve upon those conventional data storage system management applications by allowing a Drag &amp; Drop (DnD) method of rearranging logical aspects of the data storage system. In a particular embodiment, the DnD feature is implemented with the aid of a properties file. 
     In one embodiment, a method is provided, the method including (a) storing a set of drag-and-drop properties associated with an object in a properties file, the properties file being stored on a tangible computer readable medium, and (b) implementing a program in software. The program includes an instantiation of the object and a method for handling DnD features associated with the instantiated object with reference to the set of DnD properties stored in the properties file. 
     In another embodiment, a method is provided, the method including (a) receiving an indication that a user is attempting to drag a graphical representation of an object, (b) determining the type of the object, (c) determining if the type of the object is identified by a source element in a properties file, the properties file being a text file written in a markup language and the properties file storing one or more source elements, each source element identifying a valid source for a DnDoperation, (d) if the type of the object is identified by a source element in the properties file, allowing the user to drag the graphical representation of the object, and (e) if the type of the object is not identified by a source element in the properties file, forbidding the user from dragging the graphical representation of the object. In another embodiment, computer software for performing this method is provided. Other embodiments are also provided, such as a data structure for a properties file. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing and other objects, features, and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments of the invention. 
         FIG. 1  illustrates an example computer window displaying an example object hierarchy in accordance with one embodiment. The figure also displays an example of a DnD operation. 
         FIG. 2  illustrates an example system for use in practicing an embodiment. 
         FIG. 3  illustrates an example properties file of one embodiment. 
         FIG. 4  illustrates an example method for performing a DnD operation in accordance with one embodiment. 
         FIG. 5  illustrates an example method for developing a software application to perform a DnD operation in accordance with one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  depicts a window  30  of a data storage system management application displaying an example object hierarchy  32  of the data storage system. For example, a domain is shown in an expanded format, having within it hosts, storage processor A, storage processor B, a physical folder, a LUN folder, a RAID groups folder, and a storage groups folder. The elements with a “+” sign next to them are displayed in a collapsed format, while the elements with a “−” sign next to them are displayed in an expanded format. 
     As depicted, storage group  1  includes one LUN, LUN 2. Some objects may be dragged in order to alter the logical arrangement of the data storage system. For example, a user may drag LUN 1 onto storage group  1 , as depicted by arrow  34 . This operation would cause LUN 1 to be added to storage group  1 . 
       FIG. 2  depicts an example system  38  for use in practicing an embodiment. Host  40  is connected to a network  42 . Host  44  and host  46  might also be connected to the network  42 . One or more storage enclosures (SEs)  48  are also connected to the network. SE  48  contains a plurality of disk drives  50 , for example, 240 disks  50 . SE  48  also contains two storage processors  52 ,  54 . 
     Host  40  connects to the network  42  by means of a network interface  56 . Host  40  also contains local storage  58 , a processor  64  (which may include one CPU or multiple CPUs running in parallel), and memory  66 . Local storage  58  stores a properties file  62 , located within a path  60 . 
     Memory  68  includes a management application  68 , which includes a drag &amp; drop subsystem  70 . Management application  68  runs on processor  64  and accesses storage hierarchy  32 , which is stored in memory  68 . Management application  68  is able to access properties file  62 . 
       FIG. 3  depicts an example properties file  62  of one embodiment. As depicted, properties file  62  is an XML file, having an introductory XML tag at the beginning. It should be understood, that in other embodiments, properties file  62  could be another type of markup file, such as an SGML file. In yet other embodiments, properties file  62  could be yet another type of file, such as a binary data file. 
     As depicted in  FIG. 3 , properties file  62  includes a header  82  and a footer  84 . Header  82  and footer  84  may represent a drag &amp; drop element, as indicated by the &lt;Dnd&gt; and &lt;/Dnd&gt; tags. 
     Between the header  82  and footer  84 , properties file  62  contains one or more source elements  86  (for example, source elements  86 ( a ),  86 ( b )). It should be understood that in some embodiments, the properties file  62  can contain multiple source elements, while in other embodiments, several properties files  62  are maintained, each properties file  62  including only one source element  86 . Each source element  86  contains a header  88 , one or more body elements  90 , and a footer  92 . Header  88  is a start-tag containing an identification of the element type (in this case “Event” indicating a source element) and an attribute definition  94  defining the SourceKey attribute. In first source element  86 ( a ), SourceKey is defined to be EV_LUN, indicating that the source element represents a LUN. In second source element  86 ( b ), SourceKey is defined to be EV_Host, indicating that the source element represents a Host. The presence of a source element  86  with a particular SourceKey definition in a properties file means that a drag &amp; drop resource corresponding to that SourceKey definition is a valid draggable element. Footer  92  is an end-tag, formally closing the source element in accordance with standard XML. 
     Body elements  90 , such as target elements  90 ( a - d ), define valid drag &amp; drop elements onto which a source drag &amp; drop element may be dropped. Each target element  90  includes two attribute definitions  96 ,  98 . Target definition  96  defines TargetKey to be a particular valid drag &amp; drop target element onto which the source element defined by the SourceKey of the parent source element may be dropped. Action class definition  98  defines ActionClassName to be a reference to an action class to be called when the source element defined by the SourceKey of the parent source element is dropped on the target defined by TargetKey. As depicted, ActionClassName is a fully qualified JAVA method name. 
     According to properties file  62  as depicted in  FIG. 3 , a LUN element is a draggable element, which may be dropped onto a storage group (represented by TargetKey=“EV_Virtual Array”), a RAID group (represented by TargetKey=“EV_RaidGroup”), or another LUN (represented by TargetKey=“EV_LUN”), while a Host element is also a draggable element, which is droppable only on a storage group (represented by TargetKey=“EV_Virtual Array”). When a LUN element is dropped onto a storage group, the JAVA method com.company.product.storagefunctions.AddLUNToStorageGroup is called. When a LUN element is dropped onto a RAID group, the JAVA method com.company.product.storagefunctions.AddLUNToRaidGroup is called. When a LUN element is dropped onto another LUN, the JAVA method com.company.product.storagefunctions.ExpandLUNActions is called. When a Host element is dropped onto a storage group, the JAVA method com.company.product.storagefunctions.AddHostToStorageGroup is called. 
       FIG. 4  depicts a method  100  performed by a computer, such as host  40  from  FIG. 2 , while running storage management application  68 , using drag &amp; drop subsystem  70 . In step  110 , host  40  receives an indication that a user is attempting to drag a graphical representation of an object across a computer screen. For example, the user attempts to drag LUN 1 of object hierarchy  32  of  FIG. 1 . It should be understood that the dragged object is a drag &amp; drop object, for example as defined in the JAVA standard java.awt.dnd package as well as in the standard Swing library. The notification may be made by a JAVA watch class, such as the javax.swing.TransferHandler class as is well-understood in the art, although other well-known means of notification may be used as well. 
     Upon receiving the indication of a drag operation, step  120  is performed. In step  120 , host  40  determines the type of the dragged object. Thus, in the example, the type of the object would be EV_LUN, since it is a representation of a LUN being dragged. Once this is done, in step  130 , it is determined if that object type is identified by a source element  86  of properties file  62  (see  FIG. 3 ). If the object type is not identified by a source element  86  in the properties file  62 , then, in step  133 , the user is forbidden from dragging the graphical representation of the object across a computer screen. However, in the current example, since properties file  62  includes the line &lt;Event SourceKey=“EV_LUN”&gt;, in step  135 , the user is permitted to drag the object. 
     In a continuation of method  100 , the user may attempt to drag the object over another object. Thus, continuing in the above example, the user may attempt to drag LUN 1 over Storage Group  1 . Thus, in step  140 , host  40  receives an indication that the user has dragged the graphical representation of the dragged object over a graphical representation of another object, the other object being another logical or physical unit of a data storage system. Following step  140 , in step  150  host  40  determines the type of the other object over which the first object was dragged. Thus, in this example, the type of the object would be determined to be an EV. VirtualArray, since it is a representation of a storage group. 
     In step  160 , host  40  determines if the type of the other object is identified by a target element  90  in the properties file  62  nested within a source element  86  which references the object, the target element  90  identifying a valid target for a drag-and-drop operation having a source identified by the corresponding source element  86 . If not, operation proceeds to step  163 , forbidding the user from dropping the first object over the second object. If, however, the proper target element  90  is found within the properties file  62 , then operation proceeds to step  165 , allowing the user to drop the first object over the second object. Thus, in the present example, because the source object is a LUN, host  40  examines source element  86 ( a ) (having SourceKey=“EV_LUN”) for a target element  90  having an attribute definition TaregtKey=“EV_VirtualArray”. Because target element  90 ( a ) has this attribute definition, a storage group is a valid object over which a LUN may be dropped. 
     In some embodiments, when a first object is dragged over a valid target object, a graphical representation is made on the screen indicating that the target object is a valid target, even if the first object is not actually dropped there. For example, if the target object is displayed on-screen in a collapsed format, when a user hovers the object over the target and the target is determined to be a valid target, the target object may be expanded to be displayed in an expanded format. 
     Once a user drops the first object on the second object, step  170  may be performed, host  40  extracting a reference to an action function from target element  90 . Thus, in the current example, because the second object corresponds to target element  90 ( a ), the ActionClassName attribute definition from target element  90 ( a ) is extracted, indicating a reference to an action method identified by the JAVA fully qualified name com.company.product.storagefunctions.AddLUNToStorageGroup. Then, in step  180 , host  40  calls the referenced action function. Thus, for example, action function com.company.product.storagefunctions.AddLUNToStorageGroup might cause host  40  to modify the object hierarchy  32  stored in memory to include LUN 1 within storage group  1  and to update window  30  to indicate this change. 
     In some embodiments, instead of a reference to an action method, a reference is made to an action class. Such an action class is written to implement a standardized JAVA interface. Thus, the interface may define an abstract executeActionClass method which is to be called upon the instantiation of the particular action class that implements the interface. 
     The method  100  of  FIG. 4  may be implemented in software. The software may be stored on a tangible computer-readable medium. A tangible computer-readable medium may include, for example, a magnetic disk, an optical disk, or a non-volatile flash-based memory device. When executed by a computer (e.g., host  40 ), the software causes the method  100  to be performed. 
       FIG. 5  depicts a method  200  for developing a software application to perform a drag &amp; drop operation in accordance with one embodiment. In step  210 , a programmer stores a set of drag-and-drop properties associated with an object in a properties file  62 , the properties file  62  being stored on a tangible computer readable medium, such as local storage  58  on host  40 . Properties file  62 , in some embodiments, includes multiple sets of drag-and-drop properties associated with multiple objects. 
     In step  220 , the programmer implements various function in software, such as, for example, JAVA. In sub-step  223 , the programmer defines a class corresponding to the object and writes code causing that class to be instantiated in at least one case. In sub-step  225 , the programmer writes software code (such as, for example, JAVA code) to implement method  100 . This implementation may include writing a DnD transfer handler class, which includes a function for parsing the XML in the properties file  62  as well as functions for determining whether a drag &amp; drop object is draggable or droppable. It also contains code to call the appropriate action method when needed. 
     Method  200  is an improved method of implementing a drag &amp; drop feature because it allows the draggability and dropability of various objects to be modified without making significant changes to the software code. 
     While various embodiments of the invention have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. 
     For example, while embodiments have been described as operating in a storage system context, the invention is not so limited. Thus, in other embodiments, drag &amp; drop objects may represent objects that do not represent storage devices or other logical elements of a data storage system. 
     Furthermore, it should be understood that all embodiments which have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded. 
     Furthermore, it should be understood that the term “JAVA,” as used in this Specification, refers to the JAVA software platform, version 6.0, as promulgated by Sun Microsystems, Inc. of Santa Clara, Calif. “JAVA” was a registered trademark of Sun Microsystems, Inc. at the time of filing. It should also be understood that all references to JAVA are by way of example only. In fact, another software platform could be used instead of JAVA.