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/