We want to give the user the understanding whether he is using a refactoring or a transformation.
So we introduced the method menuItemString on RBAbstractRefactoring and it display (T) infront of the menu
item. Now since commands are invoking a driver that call the refactoring we will have to rethink the architecture.
May be the driver should return the menu name by delegate to the refactoring/transformation or not in case of
a driver calling different refactorings.
Check for example
SycRemoveVariables class >> defaultMenuItemName
"This is not really good since this is the job of the driver to invoke the refactoring
but we are transitionning"
"The method menuItemString of the refactoring is extended to show if the action is a transformation or a refactoring
Right now we do not invoke it because we call the driver and it means that we cannot honorate the menuItemString.
Or it means that this user feedback should be expressed differently.
check "
^ 'Remove'
We want to give the user the understanding whether he is using a refactoring or a transformation. So we introduced the method
menuItemString
onRBAbstractRefactoring
and it display (T) infront of the menu item. Now since commands are invoking a driver that call the refactoring we will have to rethink the architecture. May be the driver should return the menu name by delegate to the refactoring/transformation or not in case of a driver calling different refactorings.Check for example