Working with Automatic Refactoring

Analytics Designer has a concept of names for widgets and other application entities to ease the handling effort at design time.

If you as an application designer want to rename some entity, various references to it have to be adapted (mainly scripts, dynamic texts, and calculated measures). Previously, you had to do this work manually, which is a tedious job, especially for larger applications.

The new automatic refactoring automates this process as much as possible. Ideally, you don't need to do anything: the rename just works, keeping the application intact.

However, there are cases where blindly executing the rename would result in script errors. In such cases you'll be informed upfront about any issues, and you can decide to either cancel the rename operation or continue.

When you rename an application entity (either by using the Outline view or by changing the name in the side panel / styling panel), the software behaves as follows:

All scripts (both event handlers and script functions) without script errors will be adapted automatically.

Note

If the script declares a local variable with the same name as the new name specified during the rename operation, the local variable will be automatically renamed, using the pattern <oldName>_$.

Example: The script declares var OkButton = Button_1;, and now you rename Button_1 to OkButton. Then the script will be changed to var OkButton_$ = OkButton;
If the renamed entity is a script variable, two additional refactorings will be done automatically:
- All dynamic texts that reference the script variable will be adapted to use the new name.
- All calculations that reference the script variable (which in this case has to be of type number or integer) will be adapted to use the new name.

In the following special cases, you have to interact with the system:

Special Case/System Response	Options
If the renamed entity is a script variable which is exposed via URL parameter, a confirmation dialog will pop up to say this might break links to this application (those links that set the script variable via URL parameter).	You can continue or cancel the refactoring.
If occurrences of the renamed entity have been found in scripts which have script errors, a confirmation dialog will pop up to say scripts with errors will be skipped, and that you'll have to manually adapt the script.	You can continue or cancel the refactoring.
If occurrences of the renamed entity have been found in a script that has (read-only) input parameters which conflict with the new name, a confirmation dialog will pop up to inform you that the script will be skipped, and that you'll have to manually adapt it. Example The event handler for onPostMessageReceived has two event parameters, `message` and `origin`. The script has an occurrence of some application entity that should now be renamed to `message`. This conflicts with the event parameter, and this conflict can't be resolved. Note that the same example can also be applied to script functions, where the new name conflicts with a script function argument name.	You can continue or cancel the refactoring.
If scripts use a built-in object (like `console`, `ArrayUtils`, `MemberDisplayMode`) which conflicts with the new name, a confirmation dialog will pop up to inform you that the scripts will be skipped, and that you'll have to manually adapt them. Note In this case the scripts do not need to contain a reference to the renamed entity.	You can continue or cancel the refactoring.