Matisse UI Builder Refactor Custom Code Section Issues
Enumerated on this page should be different issues and scenarios with refactoring and custom code sections. Custom code sections are an interesting case as there are no mappings from the Java file directly to the sections in the XML .form file. The form file more or less drives the creation of the Java code. So, indirectly there may be ways to solve certain issues by first looking to the Java source code.
- The user can create a new global or local variable using a non-FQN class name within the custom code. non-FQN class names are harder to track down as the import statements will need to be examined to discern what the exact class name is if needed. Also, a refactoring can take place while the class is not compilable. This means there may not yet be a class name in the import statements. Thus the classpath will have to be examined, and if on class name collision an error will need to be raised. This will affect class re-names and possibly other scenarios.
- The user can define an inner class within custom code. This code may then not be compilable. The Java source support may possibly not be able to tell us the class name. This class name may be used in other custom code.
- This class may be used in other custom code and the class may not be compilable which means finding the class during class renames will be difficult, though maybe in this case refactoring will not work anyways...
- This class may be defined public and may be accessed from other classes. This would be a poor design and bad place to put such a class, but it is possible. The user may wish to rename this class which means the editor will kick off refactoring for the inner class rename.