Class properties inheritance
This document aims at presenting how various class characteristics inherit from the parent class.
The evaluation is made on how iTop will behave in the end. For instance, the comment on the class has solely an impact on the generated PHP code, while relations will change the way an impact diagram is built (and the inheritance has no visible impact on the compiled PHP code!)
Encountered cases are:
-
No: the characteristic is declared explicitely for each subclass, by default it is considered empty/undefined
-
Inherit: inherited from the parent class, or complete redefinition can be done on subclasses
-
Inherit / additivity : items could be added in the subclasses
-
Inherit / additivity + overload : items could be added or redefined in the subclasses
The nodes given are the smallest entity that is taken into account (granularity), meaning that redefining only a subpart of the node requires a copy of the rest (explicit copy of other subnodes).
Nodes are given as their relative path under
<itop_design>/<classes>/<class>.
For instance “properties / is_link” refers to…
<itop_design> <classes> <class id="Server"> <properties> <is_link> </is_link> </properties> </class> </classes> </itop_design>
| XML Node | Inherited | Comments |
|---|---|---|
<parent> |
n/a | |
<properties> /
<is_link> |
No | Is inheritance compatible with links? |
<properties> /
<comment> |
No | |
<properties> /
<category> |
No | |
<properties> /
<abstract> |
No | Same as in PHP inheritance scheme |
<properties> /
<key_type> |
No | Should be consistent with a given class tree |
<properties> /
<db_table> |
No | Non sense! |
<properties> /
<db_key_field> |
No | |
<properties> /
<db_final_class_field> |
No | |
<properties> /
<naming> / <attributes> |
No | |
<properties> /
<naming> /
<complementary_attributes> |
No | |
<properties> /
<field_semantic> /
<image_attribute> |
Inherit | |
<properties> /
<field_semantic> /
<state_attribute> |
Inherit | |
<properties> /
<order> |
No | |
<properties> /
<style> / <main_color> |
Inherit | |
<properties> /
<style> /
<complementary_color> |
Inherit | |
<properties> /
<style> / <icon> |
Inherit | |
<properties> /
<reconciliation> |
No | |
<properties> /
<indexes> |
No | n/a, similar the table name definition |
<properties> /
<archive> / <enabled> |
n/a | Must declared consistently within the whole class tree. Otherwise an error is issued |
<properties> /
<obsolescence> /
<condition> |
Inherit | |
<properties> /
<uniqueness_rules> |
Inherit / additivity | 🚧 Does it allow the redefinition of an inherited rule? |
<fields> |
Inherit / additivity | |
<lifecycle> |
No | |
<methods> |
Inherit / additivity + overload | Based on PHP class methods inheritance |
<relations> |
Inherit / additivity + overload | TODO: check the overloading part: done late at runtime! |
<presentation> /
<details> |
Inherit | |
<presentation> /
<search> |
Inherit | |
<presentation> /
<default_search> |
Inherit | |
<presentation> /
<list> |
Inherit |
Some of the tags which would be nice to overwrite:
-
Mandatory: because its a database setting, workaround: using GetAttributeFlags() method -
Default value: its also currently a database setting, workaround: using OnInsert() method -
Filter: for this one there is no workaround 😦 appart from moving and duplicating the field at the child level.
Only one thing can be overwritten on the children classes easily, its the dictionary entries, including the values labels of an Enum.