Nautilus extensions questions
Ben with pavel we are looking at Nautilus extensions because some of them should be moved to the extended packages. Now I was wondering why TClassDescription is extended with menu see below. I imagine that this is because you do not have a classWrapper for the UI. Is it correct? Then I wonder if there is not a pattern where we should wrap elements and attach to the wrapper such behavior. codeRewritingClass: aBuilder | target | target := aBuilder model. (aBuilder item: #'Rewrite Code') action: [ target refactor rewriteCode ]; parent: #'Code Rewriting'; order: 0. (aBuilder item: #'Search Code') action: [ target refactor searchCode ]; parent: #'Code Rewriting'; order: 100. (aBuilder item: #'Type class') action: [ target refactor typeClass ]; parent: #'Code Rewriting'; order: 200; withSeparatorAfter. (aBuilder item: #'Category Regex') action: [ target refactor categoryRegex ]; parent: #'Code Rewriting'; order: 300. (aBuilder item: #'Class Regex') action: [ target refactor classRegex ]; parent: #'Code Rewriting'; order: 400. (aBuilder item: #'Protocol Regex') action: [ target refactor protocolRegex ]; parent: #'Code Rewriting'; order: 500. (aBuilder item: #'Source Regex') action: [ target refactor sourceRegex ]; parent: #'Code Rewriting'; order: 600; withSeparatorAfter.
Ask Sebastien since it seems he is the author. I can not help more Ben On 11 Dec 2013, at 11:31, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ben
with pavel we are looking at Nautilus extensions because some of them should be moved to the extended packages. Now I was wondering why TClassDescription is extended with menu see below. I imagine that this is because you do not have a classWrapper for the UI. Is it correct?
Then I wonder if there is not a pattern where we should wrap elements and attach to the wrapper such behavior.
codeRewritingClass: aBuilder | target | target := aBuilder model.
(aBuilder item: #'Rewrite Code') action: [ target refactor rewriteCode ]; parent: #'Code Rewriting'; order: 0.
(aBuilder item: #'Search Code') action: [ target refactor searchCode ]; parent: #'Code Rewriting'; order: 100.
(aBuilder item: #'Type class') action: [ target refactor typeClass ]; parent: #'Code Rewriting'; order: 200; withSeparatorAfter.
(aBuilder item: #'Category Regex') action: [ target refactor categoryRegex ]; parent: #'Code Rewriting'; order: 300.
(aBuilder item: #'Class Regex') action: [ target refactor classRegex ]; parent: #'Code Rewriting'; order: 400.
(aBuilder item: #'Protocol Regex') action: [ target refactor protocolRegex ]; parent: #'Code Rewriting'; order: 500.
(aBuilder item: #'Source Regex') action: [ target refactor sourceRegex ]; parent: #'Code Rewriting'; order: 600; withSeparatorAfter.
On 11 déc. 2013, at 11:31, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ben
with pavel we are looking at Nautilus extensions because some of them should be moved to the extended packages. Now I was wondering why TClassDescription is extended with menu see below. I imagine that this is because you do not have a classWrapper for the UI. Is it correct?
Then I wonder if there is not a pattern where we should wrap elements and attach to the wrapper such behavior.
I think there is a pattern too. Each time instances of a class are used by many parties, each party will potentially patch some custom information and behavior in the class. So in the end you have a big class with tons of responsibility (for example Class ClassDescription and Behavior) where you could have a small class with many views used by parties. With a proxy that has it's own behavior and state you can represent point of views on an object. You can for example have a UI view on a class.
codeRewritingClass: aBuilder | target | target := aBuilder model.
(aBuilder item: #'Rewrite Code') action: [ target refactor rewriteCode ]; parent: #'Code Rewriting'; order: 0.
(aBuilder item: #'Search Code') action: [ target refactor searchCode ]; parent: #'Code Rewriting'; order: 100.
(aBuilder item: #'Type class') action: [ target refactor typeClass ]; parent: #'Code Rewriting'; order: 200; withSeparatorAfter.
(aBuilder item: #'Category Regex') action: [ target refactor categoryRegex ]; parent: #'Code Rewriting'; order: 300.
(aBuilder item: #'Class Regex') action: [ target refactor classRegex ]; parent: #'Code Rewriting'; order: 400.
(aBuilder item: #'Protocol Regex') action: [ target refactor protocolRegex ]; parent: #'Code Rewriting'; order: 500.
(aBuilder item: #'Source Regex') action: [ target refactor sourceRegex ]; parent: #'Code Rewriting'; order: 600; withSeparatorAfter.
participants (3)
-
Benjamin -
Camille Teruel -
Stéphane Ducasse