From: <lex at cc.gatech.edu>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Monday, September 27, 2004 1:13 AM
Subject: Re: #perform:#orSendTo: question


> "Boris Gaertner" <Boris.Gaertner at gmx.net> wrote:
> > That is, the default behaviour of a model is to
> > refuse responsibility for the menu items!
>
> So, why build menus whose menu items do not know who to target?  Instead
> of having one target for the whole menu, why not specify a ttarget for
> each item, and set the target correctly?
>
> I haven't looked closely, but I wonder why it doesn't work that way.
>
Well, CustomMenus have their targets (one for every menu
item if a common target is not a suitable choice), but the simpler
SelectionMenus do not have a target at all. Classes
PopUpMenu and SelectionMenu are remnants from
MVC, but they have their advantages: Just because
they do not have targets, they can be used on a
"build once, use forever" policy. That policy is further
supported by the convention that a controller should
provide a default implementation, but the model
should be given a chance to do something different.

A "build once - use forever" menu can live in
the image for years. Some prominent examples
are:

StandardSystemController >>ScheduledBlueButtonMenu
ParagraphEditor>> TextEditorYellowbuttonMenu

A CustomMenu can be created for quite short-living
targets, e.g. for a morph, a view or the like. It is
obvious that such menues should not be stored for
repeated use. CustomMenues are very convenient,
but they are used under a "use once and throw away"
policy.

Greetings, Boris