That's the main problem I'd like to solve by having install be one registered service of many that can handle packages. The design would allow the user to choose the tool he wants, and have many installers active for the same package.
Daniel
Avi Bryant avi@beta4.com wrote:
On Tue, 29 Oct 2002 goran.hultgren@bluefish.se wrote:
(I don't necessarily recommend updating through SqueakMap, though - better would be to file it in clean to a new image. Need to get that SMDVSInstaller going...)
Exactly! :-)
Looking at that again, I remembered what my other problem was with #canInstall:, that I forgot to mention in my last post - since DVS files are just .st, they get snapped up by the default installer before the DVS installer ever gets a chance...
What I've done before in similar situations is to do a leaf-first search, so that subclassing an existing installer (and adding narrower criteria) is feasible.
I propose the following change to SMInstaller class:
classForPackage: aPackage "Find the most specialized subclass that wants to handle the package."
self subclasses do: [:ea | (ea classForPackage: aPackage) ifNotNilDo: [:class | ^ class]].
^ (self canInstall: aPackage) ifTrue: [self]
danielv@netvision.net.il wrote:
That's the main problem I'd like to solve by having install be one registered service of many that can handle packages. The design would allow the user to choose the tool he wants, and have many installers active for the same package.
I am digging through my emails and just wanted to say that I am working on a design like the above. It will be in the next release of SM. It will among other things typically give you "Install using DVS" and "Install as a simple filein" for a DVS classified package (wich can be installed both ways).
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
danielv＠netvision.net.il -
goran.hultgren＠bluefish.se