[D4] Possible bug in Presenter>>on:

I'm not sure if this is a bug or by design.  As of D4, Presenter>>on: tests
whether its argument is nil, and only self sends #model: if it is not.

The effect of this is that presenters don't get a chance to initialise their
sub-models unless they have a non-nil model themselves.  To me that looks
wrong, and since (in the MVP nightschool thread) Andy has just written:

> If
> you don't have an overall model that the presenter should own, then you
> don't need to override the class side #defaultModel method since the
default
> will simply answer nil. Usually it is the job of the composite presenter's
> #model: method to take a composite model and split it up into individual
> component models and hand these over to the the various sub-presenters. In
> this case, we don't have a composite model so nil will be passed through.
> However, this is the place to go and locate your individual component
models
> and assign them to the various sub-presenters in your composite.

it sounds as if it's probably an over-optimisation.

    -- chris

Chris,

> I'm not sure if this is a bug or by design.  As of D4, Presenter>>on:
tests
> whether its argument is nil, and only self sends #model: if it is not.

D2 and D3 both have the same code as D4 and their behaviour with a nil model
is the same, #model: does not get called.

> The effect of this is that presenters don't get a chance to initialise
their
> sub-models unless they have a non-nil model themselves.  To me that looks
> wrong,

I see what you mean, the behaviour should be the same irrespective of
whether the Presenter has a Model or not, but I guess the advantage of the
current method is that you don't have to protect all of the Presenter
subclasses against being passed a nil model.

Swings and roundabouts I suppose. Extra work in every #model: method or
having to add #onViewOpened: if the Presenter has no Model.

Ian

Ian,

> > I'm not sure if this is a bug or by design.  As of D4, Presenter>>on:
> tests
> > whether its argument is nil, and only self sends #model: if it is not.
>
> D2 and D3 both have the same code as D4 and their behaviour with a nil
model
> is the same, #model: does not get called.

So they did; odd, that.  I noticed this when a thing of mine with an
intentionally-nil model stopped working.  I'd assumed it was because of the
switch D3->D4, but maybe I'd changed something else at the same time.
Easily done...

> > The effect of this is that presenters don't get a chance to initialise
> their
> > sub-models unless they have a non-nil model themselves.  To me that
looks
> > wrong,
>
> I see what you mean, the behaviour should be the same irrespective of
> whether the Presenter has a Model or not, but I guess the advantage of the
> current method is that you don't have to protect all of the Presenter
> subclasses against being passed a nil model.
>
> Swings and roundabouts I suppose. Extra work in every #model: method or
> having to add #onViewOpened: if the Presenter has no Model.

I'm not so sure.  I don't have any nil-checks in my Presenters and would be
quite happy to get walkbacks if my app was wrongly started with a nil model,
in fact I'd prefer that to having my #model: code silently circumvented.
Also, I don't like putting initialisation code in #onViewOpened if I can
help it -- for aestheic reasons more than practical, I admit.

OTOH, I haven't checked to see how much OA code "knows" that #model: will
just not be called with nil.

> Ian

    -- chris