An ugly question about menu and domain objects
Hi I have domain objects for example logs. And I have a UI. Now I would like to let the programmer to extend the Log items (either by subclassing or extensions) and add new actions. For example I would like that the compiler is able to define errors as log items so that after we can go to the log panel and press 'identify' and that we jump to the place in the code. Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus. Stef
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
yes so far I added menus "ugly just to brainstorm and get something working now" ^ #(('inspect' #inspect)) to build menus but I find that not that nice On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
What I didi for Nautilus was to use pragmas, this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). And NautilusRefactoring knows how to communicate with Nautilus. This way, the domain abject can stay clean, and I have a special class for menu :) Ben On Jun 30, 2013, at 7:55 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes so far I added
menus "ugly just to brainstorm and get something working now"
^ #(('inspect' #inspect))
to build menus but I find that not that nice
On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Ok I will look at it or you will show me. For now I'm in brainstorming and API extension stabilisation phase. Stef On Jun 30, 2013, at 8:23 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
What I didi for Nautilus was to use pragmas, this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). And NautilusRefactoring knows how to communicate with Nautilus.
This way, the domain abject can stay clean, and I have a special class for menu :)
Ben
On Jun 30, 2013, at 7:55 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes so far I added
menus "ugly just to brainstorm and get something working now"
^ #(('inspect' #inspect))
to build menus but I find that not that nice
On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Where can I look at this code? Doru On Sun, Jun 30, 2013 at 8:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Ok I will look at it or you will show me. For now I'm in brainstorming and API extension stabilisation phase.
Stef
On Jun 30, 2013, at 8:23 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> wrote:
What I didi for Nautilus was to use pragmas, this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). And NautilusRefactoring knows how to communicate with Nautilus.
This way, the domain abject can stay clean, and I have a special class for menu :)
Ben
On Jun 30, 2013, at 7:55 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes so far I added
menus "ugly just to brainstorm and get something working now"
^ #(('inspect' #inspect))
to build menus but I find that not that nice
On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- www.tudorgirba.com "Every thing has its own flow"
for the logger in StephaneDucasse/SystemLogger/ But I'm not really happy. Do not use the configuration since I was editing it. Stef On Jun 30, 2013, at 10:11 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Where can I look at this code?
Doru
On Sun, Jun 30, 2013 at 8:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Ok I will look at it or you will show me. For now I'm in brainstorming and API extension stabilisation phase.
Stef
On Jun 30, 2013, at 8:23 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
What I didi for Nautilus was to use pragmas, this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). And NautilusRefactoring knows how to communicate with Nautilus.
This way, the domain abject can stay clean, and I have a special class for menu :)
Ben
On Jun 30, 2013, at 7:55 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes so far I added
menus "ugly just to brainstorm and get something working now"
^ #(('inspect' #inspect))
to build menus but I find that not that nice
On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 7:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus.
you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- www.tudorgirba.com
"Every thing has its own flow"
participants (4)
-
Benjamin -
Damien Cassou -
Stéphane Ducasse -
Tudor Girba