Why I thought of having a generic refactoring interface is because then we can even expose it into velocity scripting. Behind the scenes this interface implementation will use various refactoring components to perform well defined (high-level) refactoring operations...
You can do the same with small many small components, the difference is purely at the syntax level:
$refactorings.get('splitDocument').refactor({'criterion' : 'headings', 'headerLevel' : 2})
which is equivalent to:
$refactorings.splitDocument.refactor({'criterion' : 'headings', 'headerLevel' : 2})
vs:
$refactorings.splitDocument({'criterion' : 'headings', 'headerLevel' : 2})
I think that having an umbrella component is bad, since it means that it needs to be updated for each new refactoring we introduce. And if we want to allow third party refactorings, then there should be a way to access refactoring that are not covered by the umbrella.
Ok, I understand. So we currently have the DocumentSplitter component but it might have to be refactored to support the use cases you have mentioned. Thanks. - Asiri
We should answer questions like:
- Do we need a preview, like Eclipse does?
- How to make them reusable both from XEclipse, scripting and the web UI? - How do we customize the refactorings? Passing a map to the main method is a good solution? - How to deal with errors? A common problem is insufficient rights. - Should this be transactional?