In MDriven, we have the LeftSide menu – now also accompanied by the Toolbar – to show actions that the user can perform.
There are two kinds of actions: Class Actions and View Model Actions (Global Actions only appear in the Main Menu).
ViewModel actions are locally defined within the ViewModel context where they operate – they gain access to data through the vCurrent_ and vSelected variables in the view. This type of action is great, but if you need the same operation in other ViewModels, it may be tedious to recreate the action in all these views.
For this purpose, the ClassAction was introduced. ClassActions are owned by its type (its class), and it will be eligible for popping up whenever any ViewModel displays objects of that type. This is very productive since you will be able to reach the action from past as well as current ViewModels you work on without the need to manually add them. Even future ViewModels that you have not yet created will get the action if it shows objects of that type. ClassActions reach the object via the self-variable in OCL/EAL.
It turned out that even if ClassActions really pushed productivity to the max, they also lacked common decency, and they popped up even in places where you did not want them.
To mitigate this rude “up popping of ClassActions”, we introduced the ability to opt them out from any particular level on any particular ViewModel. This ability was added many years ago, and it is an important function needed to design sane and user-friendly information systems – we call this concept “action opt out”.
Now however – as some clients and models has grown so big and covers so many different use-cases that it is almost unlikely that the any random ClassAction actually should show in a ViewModel only because a matching typed object is present – we must take another step to avoid decreased developer productivity due to the need to hunt for places of action opt out in existing ViewModels (that may be more than a thousand).
The new thing
To ensure developer productivity on large models, we now introduce a default-opt-out option per ViewModel. What this means is that we flip the presumption that a ClassAction that fits on type is opt-in in that ViewModel, and instead we set it as opt-out. This means that when you add a new ClassAction, it will still be available in the matching ViewModels and Nestings, but it will show as opt-out, and you would need to explicitly opt it in to make it show to the user.
You turn this new behaviour on in the ViewModel editor tree. The switch does not change anything about your existing choices, but it flips what data we actually save regarding opt in/out in the spans file – and it affects what will happen when you create new ClassActions.
You can set the value that new ViewModels should get from the packages.
If you want to set the behaviour on ALL your existing ViewModels, there is a function under Extras:
