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.
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