Efficiently Handling Many Options

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

Efficiently Handling Many Options

Eric Taylor
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


Reply | Threaded
Open this post in threaded view
|

Re: Efficiently Handling Many Options

Chris Uppal-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Efficiently Handling Many Options

Eric Taylor
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

> -----Original Message-----
> From: Chris Uppal [mailto:[hidden email]]
> Posted At: Monday, July 17, 2006 3:03 AM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Efficiently Handling Many Options
> Subject: Re: Efficiently Handling Many Options
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Efficiently Handling Many Options

Eric Taylor
In reply to this post by Chris Uppal-3
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

> -----Original Message-----
> From: Chris Uppal [mailto:[hidden email]]
> Posted At: Monday, July 17, 2006 3:03 AM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Efficiently Handling Many Options
> Subject: Re: Efficiently Handling Many Options
>
> 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