Hi

I had lot of fun cleaning the file list so that we we do a major shrink we do not have tons of obsolete class reference. The idea is that every tools should register to the file list that will then use this information to dynamically propose action.

I hope this could be integrated into the image even if there is a lot of small changes. This is this kind of architecture that can help Squeaqk to be modular and clean.

Stef

Here is a part of the preamble

Author: Henrik Gedenryd, Gerald Leeb and Stephane Ducasse

Version 3.0 - 16 Nov 2001 Prerequisites: HookForRemoveFromSystem.cs version 1. SUnit any version

This changeset introduces an important architectural change in the design of the FileList. The FileList now proposes a registration mechanism to which any tools the filelist use ***MUST*** register. This way it is possible to load dynamically a new tool or unload and to have the FileList automatically updated. This change supports a decomposition of Squeak and removes problem with dead reference to classes after a major shrink.

Tools should implement the method fileReaderServicesForSuffix: suffix (look for sender in the image) and register to the FileList calling the class method registerFileReader: aProvider when they load in. There is a testSuite called FileListTest that presents some example.

A tool register by providing a SimpleEntryService. It is composed by a class, a menu label and a method selector having one argument. See example below. The convention right now is that the argument is the path of the selected file when one file is selected and the fileList itself when no file is selected. It seems an arbitrary choice but this is the one that avoid to declare method with explicit reference to file list in reader. Hence decouple the most the reader and the file list.

Note that this regsitration mechanism relies on the fact that the file list is on the image. In the future we may introduce another object that we know will be always in the image.

To do list: look for - self flag: #shouldBeChangedToReflectThatToolsCanBeRemoved. - self flag: #ViolateNonReferenceToOtherClasses.

stef

History:

Stef 10 November 2001.

- documented an edited the preamble + class comment. - Added the possibility to unregister a tool, to check if a given tool was registered. This help to build default menu.

- remove a bug with browseFile. Now we can also selectAndBrowse file when no file are selected in a way enforced by the registration mechanism.

- Remove one possible bug the class variable was lazzily accessed from the class side but there was an instance methods returned it directly. This would have returned nil instead of an empty collection.

- renamed some methods to use the same vocabulary

- fixed genie registration. Now genie uses the registration mechanism too. - fixed zipArchive registration - fixed alice registration - removing a class form the image also unregisters the tools for that purpose I introduced a hook method in the Class>>removeFromSystem: that per default does nothing. But using this hook instead of specializing removeFromSystem: does not let the responsibility to the class developer to call super removeFromSystem:

To do:

Check all the code and add some flag: method to indicate future work to do. check for example flag: #ViolateNonReferenceToOtherClasses and shouldBeChangedToReflectThatToolsCanBeRemoved

- For example, some classes like ServerDirectory are still directly referenced via menu action. They could be the target of another iteration.

Example:

The method FileList>>itemsForFileEnding: retrieves the menu entries via ReaderServices.

Each class can register itself as ReaderService with: FileList registerFileReader: self.

The FileList collects the service entries for a file suffix by the message #fileReaderServicesForSuffix: of each ReaderService. Example: FlashMorphReader>>fileReaderServicesForSuffix: suffix

^(suffix = 'swf') | (suffix = '*') ifTrue: [ {SimpleServiceEntry provider: self label: 'open as Flash' selector: #openAsFlash:}] ifFalse: [#()]