Return value of queryCommand: ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Return value of queryCommand: ?

Carsten Haerle
queryCommand defines a return value which however is never used. It looks
like it was for aborting the search when returning false but the code for
this is missing in queryAlong or similiar location. Is this just legacy or a
bug?

Regards

Carsten Haerle


Reply | Threaded
Open this post in threaded view
|

Re: Return value of queryCommand: ?

Blair McGlashan-3
"Carsten Haerle" <[hidden email]> wrote in message
news:41121086$0$26990$[hidden email]...
> queryCommand defines a return value which however is never used. It looks
> like it was for aborting the search when returning false but the code for
> this is missing in queryAlong or similiar location. Is this just legacy or
> a
> bug?

The return value is intended as an indication as to whether the command
target recognised the command, not to control the command routing operation.
A command querying method should return false if it didn't recognise the
command, and true if it did, in either case the command routing could (and
should) continue to other command targets in the chain if a command target
prepared to accept the command has not yet been found. The command routing
code (see CommandPolicy>>queryCommand:) stops routing a command only when it
detects that a command receiver has been set. It sets the receiver itself
when a command target enables the command. To stop command routing without
enabling the command, disable the command, and set the receiver to something
other than nil (most conveniently the command target doing the disabling).

The return value can be useful in your own code, since it helps in the
implementation of a useful pattern for breaking down #queryCommand: into
pieces. I frequently use code of this general form:

queryCommand: aCommandQuery
    ^(self queryWibbleCommand: aCommandQuery)
            or: [self queryWobbleCommand: aCommandQuery
                or: [super queryCommand: aCommandQuery]]

While we are on the subject of useful command querying idioms, another
useful one is for handling context sensitive commands that map to a number
of different commands. Lets say I have a #wibbleIt command, that might do a
#wibble or a #wobble depending on selection. A useful way to implement that
is as follows:

    queryCommand: aCommandQuery
        | selector |
        selector := aCommandQuery commandSymbol.
        selector == #wibbleIt ifTrue: [
            selector := self wibbleItCommand.
            selector isNil ifTrue: [aCommandQuery isEnabled: false. ^true]].
    selector == #wobble ifTrue: [...etc.... ^true].
    selector == #wibble ifTrue: [...etc.... ^true].
    ^false

The #wibbleIt command itself is implemented as follows:

    wibbleIt
        self perform: self wibbleItCommand

To apply the two idioms together, add a parameter to the subsidiary command
querying methods, and pass the selector. Examples of both idioms can be
found in the development system tools.

Lastly if the standard CommandPolicy (actually DelegatingCommandPolicy) does
not meet your needs (it should since it is very flexible in that it involves
the presenter chain in the building of the command route, which provides it
a great deal of flexibility), then you can supply your own. Subclass
CommandPolicy, override as necessary, and then add a #commandPolicyClass
method to your Shell presenter subclass(es).

Regards

Blair