Does anyone know of a design pattern that describes a good implementation
of a way to properly enable and disable application functions based on
whatever criteria?

This seems like something that everyone would need to do at some opint in
their Smalltalk life and I was wanting to try and keep all of that behavior
from too much cluttering my controllers.

Any suggestions are appreciated.

An example of the first pattern is the menus in Envy. When building e.g. a
VisualAge CwMenu you can specify an enable block for each item. When the menu
is invoked, the block is run for each item and it's state set appropriately.
This is very nice, and the only major gotcha is to ensure that the blocks run
very quickly, because many of them will be invoked each time the menu is
displayed.

An example of the second would be to provide an "update" method in a
VisualWorks applicationModel. Whenever something happens to force a UI update,
you would run this method. It would in general update the UI, and specifically
enable or disable widgets depending on the appropriate conditions.

Adding another level of indirection on this would have command
objects and associate the conditions with the commands. Then, whatever did the
enabling or disabling would simply ask the appropriate command its state. I'm
not a big fan of command objects, so I don't tend to do this, but it would be
a quite reasonable approach.

--

The Object People               http://www.objectpeople.com                  
613.225.8812(v) 613.225.5943(f) Your Smalltalk & Java Experts

What this means is that you can model command processing as a state
machine.  At any time, all commands can be accepted by the machine, but
some will be carried out, some will be ignored and some will have errors
associated with them.  In other words, each individual command is really
a polymorphic operation; the actual command which is invoked will be the
command in the object corresponding to the system's current state.

Let me clarify this:

suppose our system has three commands, x, y, z.  In state 1, only x is
allowed (x is like a log in).  State 2 happens after x is entered.
Here, y and z are valid, but x is ignored. If z is entered (like a log
out) we return to state 1.

Define a class command interpreter with part command and operation set
state.

We now define the superclass command to have 3 operations , x, y and z.

subclass command1 defines operation x to be the log on, and operation y
and z to do nothing.

subclass command2 defines operations y and z, but does nothing upon x.

In the command1.x operation the command interpreter is told to reset its
current state to 2.  This causes the interpreter to instantiate an
object of type command2 and put it in part state.

in the command2.z operation the command interpreter is told to reset its
state to 1.  This causes the interpreter to change part to an object of
class command1.

Every time the interpreter gets a command it dispatches it to the
appropriate operation in its current part.  For example, if the part is
currently command1, an x will result in a log-in, if the part is
currently command2, x will be ignored.

: Does anyone know of a design pattern that describes a good implementation
: of a way to properly enable and disable application functions based on
: whatever criteria?

This may be too far out in left field for practical purposes, but an
interesting paper to read about this topic is Henry Leiberman's "There's
more to menus than meets the eye."  I cannot remember where it was
published. It may be available from his web pages at MIT. I don't know.

If you are familiar with the Symbolics Genera operating system, or with
the Common Lisp Interface Manager (CLIM), it is a take off from there.
Sort of a "least fixed point" of CLIM.