« Back

Default models appear for different modes/variants of same model

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Default models appear for different modes/variants of same model
community modeltype documentation adoscript trigger
Answer
4/11/14 12:11 PM
I'm trying to have default models only appear for different modes. The thing is, I can't seem to check the mode in the CreateModel event and use an Execute file, without getting error messages.
Here is what I got:
1SETG nCreateModelID: (modelid)
2CC "Modeling" GET_VIEW_MODE modelid: (nCreateModelID)
3SET modelview: (modename)
4
5IF (modelview = "ModeName") {
6  EXECUTE file: ("PATH for the default model for this mode")
7}


I get an error on the IF condition, which might be because the event happens after the model has been created. Any tip on how to avoid this problem ?

RE: Default models appear for different modes/variants of same model
Answer
4/11/14 12:12 PM as a reply to Anonymous.
The reason for this issue relates to the the components/messageports both commands/events come from. The event "CreateModel" is an even that is triggered by the "Core" and essentially is usable with a model representation in the graphical editor (you can potentially create a lot of models without the UI interaction).
The AdoScript command you use to retrieve the the VIEW MODE relates to the Modelling messageport that relates to the availability of a mdoel in the Modelling Editor to perform certain commands.

The event that could potentially be used for your implementation is the "AfterCreateModelWindow", which is triggered everytime a model is loaded in an editor, so you would need to have a toggle if the code should only be executed once.

RE: Default models appear for different modes/variants of same model
Answer
4/11/14 12:12 PM as a reply to Wilfrid Utz.
I've tried with the "AfterCreateModelWindow" event, but I still get the default instances in all the modes and not only in the two modes I want those default instances to appear.
Basically what I want to do, is that when a user creates a new model, some default non deletable instances appear in 2 of the 6 modes that come with this model.

RE: Default models appear for different modes/variants of same model
Answer
4/11/14 12:14 PM as a reply to Anonymous.
After further analysis, does this represent your scenario:

Interaction process - Default Model
a) User creates a new model of the single modeltype that is defined for your library
b) A default model is created, this model has different views which are potentially completely different from each other, but build on an overlapping set of concepts. This means that the views are not distinct from each other when it comes to defined classes and relations
c) The user should have the chance to change views and see different representations graphically. The level on how this views are related to each other (e.g. can 1 instance be potentially in 2 views?) is not yet clear.

I do believe that the views are not appropriate since they target a view on the metalevel as a class and relation filter. I am currently thinking that we could make use of the VARIANT concept in ADOxx to realize this approach. This would lead to the situation, that we would initialize the default model for all views/variants once and set the variant relation accordingly when creating. When switch views/variants, the model is redrawn and the representation is realized.

Variant Management in ADOxx
community modeltype documentation
Answer
4/11/14 12:23 PM as a reply to Wilfrid Utz.
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 Level

Add 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 Switch
Variants 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 View
A 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.
Attachments: AfterCreateObjective.asc (3.8k), VariantManagementLibrary.abl (28.6k), createConnector.asc (0.5k), createInstance.asc (0.5k), createModel.asc (9.1k)

RE: Variant Management in ADOxx
Answer
4/11/14 12:32 PM as a reply to Wilfrid Utz.
In the section "DeleteRelationInstance", relationclassid, frominstanceid, toinstanceid take some strange values...

I'll tell you what you need to do to recreate the event and you'll be able to see the strange things in the log in the modelling environment.

So first got to the fourth variant (ctrl+4). Then I try to delete the "Goal1", which is an element that shouldn't be able to be deleted. So the start is correct in the log. Dependency Links and to/from goals, but at one point there are Roles that appear in the log and I don't understand why... There is absolutely no link between a role and a goal in this variant.

Basically what I want to happen in variants 3 and 4 (crtl+3 and ctrl+4) is to create some models that appear at the start and that can't be deleted by an user, as we did in variants 1 and 2.

RE: Variant Management in ADOxx
Answer
4/11/14 12:33 PM as a reply to Anonymous.
Please find below some results from the investigation:
+ the default models are created in the bottom right corner. I am not sure if this is on purpose or I missed something in the scripts.
+ in contrast to the last version discussed, you did add instances to different views, correct? So the effect observed is actual logical having in mind the implementation of the catch mechanisms for the DeleteRelatioInstance event:

a) in a first step the deletion of the class instance is cancelled
b) since deletion of the relations happen before, that and have already taken place, the wrongly deleted relation class instances are re-created.
c) Since some relations class instances exist only in other variant views, the re-creation also re-creates the relation class instances in other views such as the ones in view 3 where the same goal is related to the role that results in the log behavior described.

To overcome this issues, I see 2 different options:
1) Make sure that only unique names exist per view - which means reverting to the last discussed version when it comes to naming of objects
2) Update the relation class instance recovery implementation to include also the variant visualization.

RE: Variant Management in ADOxx
Answer
4/11/14 12:34 PM as a reply to Anonymous.
a) Updated all relation classes to have a "__Variants__" attribute. This attribute is important to store the display options in different variants
b) Added a new modelattribute as a table to store all deleted relation instances and re-create them. The implict way through the UpdateAction event is regarded as too vulnerable and did result in unpredictable behaviour.
c) Update the event listeners in external coupling. Please find attached the extract from there as a file.
d) Commented issues and open items where necessary and marked the code I changed
Attachments: ExternalCoupling.asc (9.1k)