Attached a generic implementation of the variant management approach in ADOxx on a generic level to substitute for the view-based implementation we did discuss earlier. Please find a brief summary of the implementation below:
a) Views vs. Variants:The main difference between the two approaches is that views related to the metamodel/class level and variants can be even on instance/object level. Based on this definition, we can define variants similiar as views in the "Modi" attribute, also use the INCL and EXCL statement to perform certain view restrictions on class level and additionally have also variants on instance/model level. In order to prepare your implementation for this change,
i ) the current views have to be transformed to variants (they could also co-exist, but I do not think that in your scenario this is necessary). For my generic implementation I added 3 variants, the code would look like that in the "Modi" attribute
1MODELTYPE "Model" from:none attrrep:"DummyModelAttrRep"
2INCL "Car"
3INCL "is related to"
4VARIANT "A"
5VARIANT "B"
6VARIANT "C"
ii) Variant Setting Persistence on Instance LevelAdd a global attribute for all classes and relation to allow for instances to store information to which variant they belong and where they should be position for certain variants. This also means that the previously communicated restriction that one instance can only exist in one variant is actually not correct and you could potentially have the same instance in different variants on different positions. For the implementation and simplicity reasons I did keep the instance <-> variant relation on a 1 to 1 level.
The attribute needed is of type STRING and should be named "__Variants__". For modelling classes, just add this attribute to the top level class (__D-construct__ and __S-construct__), for relation classes, you need to add the attribute manually to each class.
b) Variants SwitchVariants are accessible in the "View" menu in the sub-element "Variants". A default variant is added named <No variant> in order to make sure that models without variants can still be imported. To make thinks more obvious, this could also be added to the quickaccess bar as specific buttons.
c) Limitation Variants in Table ViewA limitation of the approach is that the table view does not support variants and will always show all instances created in all variants
d) Interaction update: In order to make sure that newly created instances are only added to the currently active variant, 2 AdoScripts are needed to set the Position/Positions attribute correctly and append the "iuv:0" statement to the end. This statement says that the object should only be available in the current view but not in the others.
This implementation would actually overwrite the settings of variants. If you want to remove the settings menu entry for variants you can add ACTION "variants.options" visible:0 to the "Default Settings" Library attribute.
e) Default model creation: to create the default model in different variants, please see the AdoScript attached. The script is triggered for the event "AfterCreateModelWindow". Since this event is triggered every time you open a model, an additional flag as a modelattribute has been added to check whether the model has been already initialized. Model attribute "Is initialized" defined as an attribute of abstract class "__ModelTypeMetaData__" and referenced in "Modi"
The generic approach would create 3 different variant defaults, showing the letter of the variant as a model. An extension would be, to reuse objects in different variants, if you are interested in this approach I could extend the sample if needed.
Please find attached the ABL file that contains the 3 AdoScript that are triggered by the event in the library, for your reference also as separete files. To provide some traceability and debugging in the scripts I added the Debug shell and also the Debug Logging Window.
When setting up variant views in amodel programmatically, please consider to switch between variants also programmatically to persist the changes in the "__Variants__" attribute. The following snipplet will between the default variant ("") and the to be switched, also possible during the switch event.
1CC "Modeling" SET_ACTIVE_VARIANT variant:"" quiet
2CC "Modeling" SET_ACTIVE_VARIANT variant: (activeVariant) quiet
3
4ON_EVENT "BeforeExtSetVariant" {
5 IF (newvariant != "") {
6 # WORKAROUND: Switch programmatically to empty before going to new variant
7 CC "Modeling" SET_ACTIVE_VARIANT variant:"" quiet
8 }
9}
10
11
12.