Toolkits

Focus-n toolkits contain groups of “actions” that can be performed on user objects of a specific type. FIG. 15 shows the Toolkit structure 1500, which is a particular instance of a system object, containing an Object_ID 1510 that indicates the unique identifier of the toolkit, a Type_ID 1511 equals to 100 (the type identifier for toolkit objects), a Lang_ID 1512 that indicates the language of the Name 1513 and Description 1514 of the toolkit, and other fields composed by the Ref_Type_ID 1520, which is the identifier of the type of the objects to be processed by the toolkit, the {list of required toolkits} 1530, that indicates which other toolkits must be installed in the inventive system for this toolkit to work, the {list of action identifiers} 1540, that contains an array of system objects describing the actions of the toolkit, and the Computer code (reference) 1550, which provides a means for locating the computer code of a Java class (typically, a “.jar” file) for processing the actions of the toolkit.

 

FIG. 15 also shows the Action structure 1560, which is a particular instance of a system object, containing an Object_ID 1570 that indicates the unique identifier of the action, a Type_ID 1571 equals to 101 (the type identifier for action objects), a Lang_ID 1572 that indicates the language of the Name 1573 and Description 1574 of the action, a Ref_Type_ID 1580 for the type identifier of the objects to be processed by the action, an Action_ID 1585 for specifying an identifier of the action relative to the type expressed in 1580, and a {list of parameters} 1587 needed for the execution of the action. Moreover, the double arrow with the label [1..n] 1590 indicates that the list of action identifiers of the toolkit structure contains several references (at least one) to action objects.

Any Java class implementing a toolkit (as a singleton) must provide a zero-parameters constructor and the following public method:

result doAction(info, actionID, params);

The doAction() method executes the toolkit code for an action on a user object, according to info (the object), actionID (the action identifier), and params (the actual parameters for the action), and returns as the result an error code to indicate whether that action could be performed and eventually the reason for failure. If the execution of the action generates information that must be returned to the system, it will be done by reference on some parameters.

 

FIG. 16 shows an example of the organization of two toolkits with two actions each one, where one toolkit 1610 is for the type <Avatar>, which is derived from the type <Sequence>, associated to the other toolkit 1600 (see FIG. 14 for explanation on these types). The actions for toolkit 1600 are represented by structures 1620 and 1630, both referring to the type identifier of <Sequence> (1014) in 1625 and 1635, and with two distinct action identifiers in the domain of the type in 1627 (1) and 1637 (2). The actions for toolkit 1610 are represented by structures 1640 and 1650, but one action refers to the type identifier of <Sequence> (1014) in 1645 and the other action refers to the type identifier of <Avatar> (1025) in 1655. Hence, the action identifiers registered in 1647 and 1657 do not refer to the same type domain, thereby they do not conflict each other by having the same identifier (1). Moreover, the toolkit 1610 requires the existence of the toolkit 1600, which is expressed by including the object identifier in 1605 (6) in the list of required toolkits 1615.

The action referred by 1640 specifies the same type and action identifiers that the action referred by 1620. This is a mechanisms that allows to override an action for an object of an ancestor type. For example, suppose that the work of action 1 on objects of type <Sequence> is to show the next image of the sequence. Obviously, this action also applies for objects of type <Avatar> that contain two images. But, if the image to show is an object of type <Portrait>, some extra work should be done, for example, to verify the certificate of the portrait and show a marker for that verification. Therefore, the toolkit for <Avatar> must provide new code for overriding the previous action defined in the toolkit for <Sequence>. Moreover, the new action may need (at some point) to execute the code of the previous action, which is the reason for specifying that toolkit 1600 must be installed in the system for the proper working of toolkit 1610.