Suggestion - #ideModel

Andy, Blair,

Some time ago, I floated an idea about two kinds of default models.  Many
presenters are perfectly useful when connected to their default models,
others "expect" to be connected to another model.  Often the latter sort are
composites embedded in other composites, and all share either a common
(complicated) model, or their natural default models are best obtained by
creating an instance of the complex model and then choosing a part of it.
I've encountered this situation twice now, and both default models end up
doing a fair amount of binary in-filing, so they are not cheap to create.

The bottom line is that a lot of computation can be done just to create
default models that get tossed out in real use.  One could define
#defaultModel to answer nil (the default), but that breaks the Show...
command.  Just for laughs, I created an override of #show that invokes
#show:on: using #ideModel instead of #defaultModel.  Along with that, I
answer nil from #defaultModel, and answer a suitable default from #ideModel.
So far it seems to work; I can show views in the browsers and (I think
anyway) skip the overhead of creating extraneous default models.  I'll admit
that it could be fooling me, but I don't think so.

The one disadvantage of this design is that it requires a lot of care to get
right.  If I stay with it, I will probably create an ExpensiveModelPresenter
to put the #show: override in one place.  Of course, I'd gladly adopt a more
elegant alternative should one be added to the base system :)

Comments?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:ba0ac3$nqmp3$[hidden email]...

> Some time ago, I floated an idea about two kinds of default models.  Many
> presenters are perfectly useful when connected to their default models,
> others "expect" to be connected to another model.  Often the latter sort
are
> composites embedded in other composites, and all share either a common
> (complicated) model, or their natural default models are best obtained by
> creating an instance of the complex model and then choosing a part of it.
> I've encountered this situation twice now, and both default models end up
> doing a fair amount of binary in-filing, so they are not cheap to create.

This is probably not exactly what you want, but it may be of use.  You could
test whether the image is runtime in the defaultModel method and either
return nil or create and return your expensive model.  You could also make
it more fancy by additionally testing for a key down (such as shift).

I have implemented a shiftHalt method using a similar approach.  This way I
do not run into problems if I accidentally deploy code with a shiftHalt left
in.  Some variant of this test could be used in a defaultModel method.

Object<<shiftHalt
    "cdemers - 1/10/2003 Execute a halt only when the shift key is pressed.
self shiftHalt"
    (SessionManager current isRuntime not and: [Keyboard default
isShiftDown]) ifTrue: [self halt].

Chris