BUG - All renames should propagate to all other objects

[vchelaru]

Propagate changes:

• Rename category
  • Change instance variable types
  • Change derived screen/component variable types
  • If behavior, create new category in all elements that implement this, but do not remove old category (for now)
• Rename state
  • Change instance variable values
  • Change derived screen/component variable values
  • If behavior, create new state in all elements that implement this, but do not remove the old state (for now)
• Rename behavior
  • Change all components that reference it
• Rename component
  • Change all instance types that use this
  • Change all derived components
  • Change Contained Type variable
• Move component to folder
  • Change all instance types that use this
  • Change all derived components
  • Change Contained Type variable
• Rename screen
  • Change all derived screens
• Move screen to folder
  • Change all derived screens

Show preview of change (see above for details:

• Rename category
• Rename state
• Rename behavior
• Rename component
• Move component to folder
• Rename screen
• Move screen to folder

Undo should restore previous state for all propagated changes

• Rename category
• Rename state
• Rename behavior
• Rename component
• Move component to folder
• Rename screen
• Move screen to folder

[vchelaru]

I was about to start on this task but then I realized that there are some conceptual issues that need to be worked out. For this discussion, consider renaming a component. Any instances of this renamed component must also have their Base Type variable updated. Therefore, when changing a single component name, this can result in changes to other components and screens.

This isn't too bad by itself, but undo's become very complicated. Currently each Screen/Component has its own list of undo/redo history. If we undo a rename on a component, then that means we must undo the change on other components too. Should this actually be an undo/redo? Or should the undo just make the change, and then the normal refactoring logic should kick in?

If we use undo/redo, then that means that the undo must store the state of other screens/components so that it can be restored, which causes tons of problems.

If we rely on refactoring.....that might work. I need to think through refactoring to see if this introduces any problems...