Asiri Rathnayake wrote:
Also we will want to expose all theses refactoring action easily on the UI and we could maybe have a generic Refactoring interface taking described parameters and with a unique execute method exactly what we do for macros. Would be Wiki transformation where macros are XDOM transformations.
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. 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? -- Sergiu Dumitriu http://purl.org/net/sergiu/