[xwiki-devs] Designing Refactoring module
Hi Devs, I have committed the initial xwiki-refactoring module which has support for splitting a document into multiple documents. The design of the DocumentSplitter component is somewhat like http://i39.tinypic.com/28k24w4.png (there are few minor changes). Anyway, we need to think of a proper desgin for the Refactoring module that will allow us to extend this module in future. I can see two approaches for this desgin: 1. We implement each refactoring operation as a single component - like currently it is done with DocumentSplitter. But this might not be a good idea because the refactoring module itself will not provide a well-defined API to users (it will be scattered into multiple component interfaces). 2. We define a single Refactoring plexus component interface that will include all the currently suppported refactoring operations (like a facade) - this way we have a high-level refactoring interface that can be easliy understood and used by users. I think the 2 approach is more usable than the first one. WDYT? may be there is a third approach? Thanks. - Asiri
On Tue, Apr 7, 2009 at 14:06, Asiri Rathnayake <[email protected]> wrote:
Hi Devs,
I have committed the initial xwiki-refactoring module which has support for splitting a document into multiple documents.
The design of the DocumentSplitter component is somewhat like http://i39.tinypic.com/28k24w4.png (there are few minor changes).
Anyway, we need to think of a proper desgin for the Refactoring module that will allow us to extend this module in future. I can see two approaches for this desgin:
1. We implement each refactoring operation as a single component - like currently it is done with DocumentSplitter. But this might not be a good idea because the refactoring module itself will not provide a well-defined API to users (it will be scattered into multiple component interfaces).
2. We define a single Refactoring plexus component interface that will include all the currently suppported refactoring operations (like a facade) - this way we have a high-level refactoring interface that can be easliy understood and used by users.
I think the 2 approach is more usable than the first one.
WDYT? may be there is a third approach?
2. sounds the contrary of extensibility. We need a different component for each (groups of) refactoring action, the question is not here IMO. If we really need a general RefactoringAll which use the different components behind the scene we can do it but I doubt we need it.
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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. On Tue, Apr 7, 2009 at 14:31, Thomas Mortagne <[email protected]> wrote:
On Tue, Apr 7, 2009 at 14:06, Asiri Rathnayake <[email protected]> wrote:
Hi Devs,
I have committed the initial xwiki-refactoring module which has support for splitting a document into multiple documents.
The design of the DocumentSplitter component is somewhat like http://i39.tinypic.com/28k24w4.png (there are few minor changes).
Anyway, we need to think of a proper desgin for the Refactoring module that will allow us to extend this module in future. I can see two approaches for this desgin:
1. We implement each refactoring operation as a single component - like currently it is done with DocumentSplitter. But this might not be a good idea because the refactoring module itself will not provide a well-defined API to users (it will be scattered into multiple component interfaces).
2. We define a single Refactoring plexus component interface that will include all the currently suppported refactoring operations (like a facade) - this way we have a high-level refactoring interface that can be easliy understood and used by users.
I think the 2 approach is more usable than the first one.
WDYT? may be there is a third approach?
2. sounds the contrary of extensibility. We need a different component for each (groups of) refactoring action, the question is not here IMO. If we really need a general RefactoringAll which use the different components behind the scene we can do it but I doubt we need it.
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
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... - Asiri
On Tue, Apr 7, 2009 at 14:42, Asiri Rathnayake <[email protected]> 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...
The way you described the vote in your first mail, it looks like your ask for a vote for multiple components against single component...
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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...
The way you described the vote in your first mail, it looks like your ask for a vote for multiple components against single component...
Ok, what I meant is to have a single high-level component interface for the Refactoring module. But this doesn't prevent us from having individual components for implementing various refactoring operations. Also, this is rather a discussion, i was simply putting my opinion :) - Asiri
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/
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?
On Apr 7, 2009, at 2:06 PM, Asiri Rathnayake wrote:
Hi Devs,
I have committed the initial xwiki-refactoring module which has support for splitting a document into multiple documents.
The design of the DocumentSplitter component is somewhat like http://i39.tinypic.com/28k24w4.png (there are few minor changes).
Anyway, we need to think of a proper desgin for the Refactoring module that will allow us to extend this module in future. I can see two approaches for this desgin:
1. We implement each refactoring operation as a single component - like currently it is done with DocumentSplitter. But this might not be a good idea because the refactoring module itself will not provide a well- defined API to users (it will be scattered into multiple component interfaces).
2. We define a single Refactoring plexus component interface that will include all the currently suppported refactoring operations (like a facade) - this way we have a high-level refactoring interface that can be easliy understood and used by users.
I think the 2 approach is more usable than the first one.
I don't like 2 either for the reasons mentioned. Thanks -Vincent
WDYT? may be there is a third approach?
Thanks.
- Asiri
participants (4)
-
Asiri Rathnayake -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol