"Stephan B. Wessels" wrote:
> 
> On 1/17/02 2:54 PM, "danielv at netvision.net.il" <danielv at netvision.net.il>
> wrote:
> 
> > Here's a survey of a refactoring Stef's sent to the list, in the hope
> > this will lead to accepting this change into the base image, or someone
> > else doing it better. Also it's a pretty good example of the sort of
> > changes
> > that clean up dependencies and make Squeak more modular.
> >
> > I haven't yet surveyed everything, but it's not that complicated, so
> > here're my initial findings:
> >
> > 1. Stef's purpose is to remove mentions to other classes from the
> > FileList, which basically know every file-format Squeak can do anything
> > to and every tool to do it. These dependencies currently make the system
> > much less modular. These tools should be optional, but not having them
> > in the system currently breaks the FileList.
> >
> > 2. The mechanism is pretty simple.
> > * When a class for a new tool is filed in, it's initialize method tells
> > FileList that it too can handle files.
> > * When a FileList menu is raised, it asks each file handling class what
> > services it can provide for this file ending.
> > * Each file handler returns a collection of ServiceEntries. Currently,
> > just SimpleServiceEntries.
> > * An SSE knows a reciever, a selector and a label.
> > * When the user clicks the menu item with the label in the SSE, the
> > right message is sent to the appropriate reciever. Voila.
> > * When the class is removed, it is deregistered.
> >
>  <SNIP>
> 
> When I first read this I thought, that's a great idea.  That was days ago.
> 
> Then I awoke this morning and remembered that I'd solved this "problem"
> about a year or more ago and published to the list.  I didn¹t create a
> registry but instead used the method category feature of Squeak code.  The
> technique was that the menu was built by looking for methods in a specific
> category.
> 
> When a class was installed it simply made sure it's menu additions were
> located in the proper method category and then the tool would integrate
> them.
> 
> I'm pretty sure the code I published handled FileList, the World open menu
> and one other menu.
> 


> There's nothing wrong with the idea you are working on here.  It looks fine.

Without seeing the discussion before (my domain was down): I think it is
more flexible than just using the category feature. And (de-)registering is
performed actively from the 'ServiceProvider' here.

Greetings,

Stephan

> But I just wanted to remind people there was a solution published a pretty
> long time ago.  I know of at least one person that was using too because I
> had gotten a thank you email.
> 
> I published the code more than once under a couple of different names.  One
> was ConfigurableMenus, the other was Re-factoring of menus.  There's a copy
> of he change set for V2.8a here:
> http://w3.one.net/~swessels/pages/steve/squeak/mine/refactor-menus.11mar1810
> .cs

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3