|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Interface Summary | |
---|---|
AlgorithmInterpreter | This interface is an implementation of the design pattern Interpreter in the GoF collection, to store the paths search algorithms of an EPR view, a NoThan view or the sketch view. |
CoreAlgorithm | This interface is a marker for the classes that implements the core algorithms. |
LinkRights | This interface provides detection and filtering operations about links and privileges for a given ACS. |
NodeRights | This interface is responsible for getting the rights for a node in a view, and since each implied ACS may be generic or from an AcsAddon, the main job of this class is to give the correct method to use for each ACS and each search. |
RightsMediator | This interface is an implementation of 2 gWorkInterface interfaces. |
RightsNetworkObserver | This interface is responsible to follow the property change events from all the BaseObjects associated to a view, to inform the view GraphicViewBaselistenerImpl that the rights may have changed. |
Contains interfaces to process the search of rights in the views, as a support to the gWork package. This is a part of the access path framework. The interfaces are:
A node in a view, or an analyzed node that should be an intermediate node, has a dedicated NodeRights instance and a dedicated LinkRights instance for each view it belongs to. Each instance of NodeRights and LinkRights is called by only one thread. The two effective classes may be subclasses from the AcsAddon of the node, or may be the NodeRightsImpl and LinkRightsImpl classes from the generic gWork package.
A node may be in several DisplayableLinkImpls of the same view, but it has only one NodeRights instance for each view. An ACS may have several ACSObjects in a view, but it has only one LinkRights instance for each view.
The RightsMediator instance of the view manages the associations between a node and its NodeRights instance, a node and the LinkRights instance, a view and the xxxRightsFactoryImpl, yyyUtilities and UtilityImpl instances for this view.
With the AcsAddon framework, the path search algorithms are designed in a full object-oriented structure. The framework allows to exploit the genericity of the gBase concepts in the main algorithms. It is possible to add simply any additional processing, or to alterate the generic algorithms, by the mean of new AcsAddons in ARoad0.AcsAddon.xxx.yyy.gWork packages. The framework is presented hereinafter:
the core algorithms are the larger part of the code, and they are in the 5 generic xxxRightsFactoryImpl classes in the gWork package, and the utility methods in DisplayableLinkUtilities, RightsFactoryUtilities and UtilityImpl,
the NodeRights and LinkRights generic methods; they are called by the core methods to process each node and the paths,
the NodeRights and LinkRights AcsAddon methods, with the name pattern detectAddon... or selectAddon...; the core algorithms include the test of the getXXXAddonYYY methods for the node, and if they returns true, the relevant AcsAddon method is called; for instance, in ThreeNodesRightsFactoryImpl, to take account of the AcsAddon additions in the GroupIDMember relations, the AcsAddon method selectAddonLastViewNodeAfterGroupIDMember() is called on the central group of the 3-nodes path, to detect any path like groupidmember/member/group/any AcsAddon relation/group; these AcsAddon methods are empty in the NodeRightsImpl and LinkRightsImpl classes (all the getXXXAddonYYY methods return false), and they may be overridden in the subclasses to write a code that calls some specialized AcsAddon methods,
the specialized methods of an AcsAddon are in a NodeRightsImpl or LinkRightsImpl subclass, and they are called by an AcsAddon method; for instance, in ThreeNodesRightsFactoryImpl, a developper may add a new relation IS_ALIAS between two GroupIDs in its AcsAddon, and he will do it simply by overriding the AcsAddon method selectAddonLastViewNodeAfterGroupIDMember() in his subclass of NodeRightsImpl, to call a specialized method addAliasRelationToDisplayableLink(); there is no name pattern for the specialized methods; they use the generic properties of a node and its environment, but naturally they also handle the specific properties of the AcsAddon node. Since an AcsAddon may be based on another AcsAddon, a subclass may be extended from another NodeRightsImpl or LinkRightsImpl subclass.
the interface methods ACSObjectAddon.getAddonInnerPropertiesToListen() and getAddonParentPropertiesToListen() describe the AcsAddon property change events to listen for updating the views which contains a node from such an AcsAddon.
Ease-of-use: medium. The core algorithms are complex, and it is necessary to well understand the CNot and gBase packages before any change. Nevertheless, the AcsAddon framework provides powerful and simple means to add new simulations, even if all the code in this package is not well understood.
Reliability: medium. The rights processing tests are based on the comparison of the results between the 2-nodes paths, the 3-nodes paths and the longer paths. There are no known bugs.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |