Efficiently Handling Many Options

Hello Forum,

In revisiting our XtremeCommandBars abstraction hierarchy, I'm a little
put off by the fact that there are so many methods in the class that
deal simply with the setting and clearing of option flags.

For example, there are nine docking flags for each command bar.  I have
the following for each flag (operating upon the instance variable
<dockingFlags>), with distribution across the MVP as indicated:

        #beRightDockable (M)
        #beRightUndockable (M)
        #isRightDockable (M)
        #dockRight (P)
        #isDockedRight (P)

and so on for the left, top, bottom, etc.  Multiply this by nine, and
you can see what I mean.  And these aren't the only flags.

But I'm equally put off by the following:

        #setDockingFlags:

where usage might look something like this (assuming a pool dictionary
for the constants):

        setDockingFlags: xtpRightDockable | xtpLeftDockable |
xtpFloatable

Any suggestions for streamlining?


Cheers,

Eric

Eric Taylor wrote:

> #beRightDockable (M)
> #beRightUndockable (M)
> #isRightDockable (M)
> #dockRight (P)
> #isDockedRight (P)
>
> and so on for the left, top, bottom, etc.  Multiply this by nine, and
> you can see what I mean.  And these aren't the only flags.

How about a little DockPlacement object ?  With Boolean-valued aspects:
#isLeft, #isRight, #isTop, #isBottom, #isFloating, and so on.

Add a few convenience methods to DockPlacement class for creating instances
with common configuration, and you're away...

v := ....
v allowedDocking isLeft: true.
v allowedDocking isRight.
v docking isFloating: true.
v docking isLeft.  "--> false"

BTW, don't be tempted to give a View subclass methods called #placement[:] --
it overrides a system method and leads to unexpected and hard-to-diagnose
problems.  Guess how I happen to know that :-(

    -- chris

Hello Chris,

>
How about a little DockPlacement object ?  
>

I would say that, on the surface, I'm not so sure I gain anything with
this approach.  The weightiness is simply concentrated in a different
class.

I do gain, however, in clarity and reusability as the Xtreme Suite uses
the docking metaphor in a number of different controls, not just in its
command bars controls.  So I think I'll try out your idea :).

>
BTW, don't be tempted to give a View subclass methods called
#placement[:]
>

I'm always on the lookout for that little black triangle showing an
override.  I've already suffered the consequences of failing to do that
:o.

Cheers,

Eric
and
> > you can see what I mean.  And these aren't the only flags.
>
> How about a little DockPlacement object ?  With Boolean-valued
aspects: #placement[:]
> --
> it overrides a system method and leads to unexpected and
hard-to-diagnose
> problems.  Guess how I happen to know that :-(
>
>     -- chris

Chris,

I finished implementing the docking aspect of XtremeCommandBars
according to your suggestion.  It works great!

I took the approach of Policy:

XtremeDockingPolicy
        XtremeRibbonBarDockingPolicy
        XtremeToolBarDockingPolicy
        XtremeDialogBarDockingPolicy

The creation methods of XtremeDockingPolicy simply dispatch requests to
create a specific policy in the same manner as SearchPolicy.

Thanks for the advice :-)

Cheers,

Eric
and
> > you can see what I mean.  And these aren't the only flags.
>
> How about a little DockPlacement object ?  With Boolean-valued
aspects: #placement[:]
> --
> it overrides a system method and leads to unexpected and
hard-to-diagnose
> problems.  Guess how I happen to know that :-(
>
>     -- chris